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The 5ESS Switching System: 


Introduction 


By K. E. MARTERSTECK and A. E. SPENCER, JR.* 
(Manuscript received November 14, 1984) 


This special issue of the AT&T Technical Journal is devoted to the 5ESS™ 
switch. In this introductory paper the authors provide some historical back- 
ground; outline the characteristics of this new, advanced system; and summarize 
its architecture, features, and status. 


I. BACKGROUND 


In March 1982, the first 5ESS switch was cut over in Seneca, 
Illinois. This new, multifunctional, time-division digital switching 
system is the product of development efforts at AT&T Bell Laboratories 
that can be traced back to the 1950s. Development of the 5ESS 
electronic switch was, and continues to be, driven by the worldwide 
evolution of both switching technologies and expanding telecommuni- 
cations needs. 

To introduce the more detailed articles that follow, this paper offers 
a brief history of AT&T Technologies electronic switches, discusses 
the characteristics of the new 5ESS switch, and introduces some of 
its technologically innovative features.? 


1.1 Local switching systems 


The first general-purpose electronic switch, the 1ESS™ switch? 
(which was cut over in Succasunna, New Jersey, in May 1965), 
contained a space-division switching network and a digital electronic 
data processor under Stored Program Control (SPC).' It was primarily 
intended to serve urban areas with large numbers of lines (between 


* Authors are employees of AT&T Bell Laboratories. 
t Acronyms and abbreviations used in the text are defined at the back of the Journal. 
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10,000 and 65,000) and heavy traffic, including many business customers. 
The 2ESS switch, introduced in 1970, was designed to serve fewer 
lines (2000 to 10,000) and to meet the lighter traffic needs of suburban 
residential areas. In 1976 the smallest of AT&T Technologies space- 
division electronic switching systems, the 3ESS switch, began meeting 
the needs of rural Community Dial Offices (CDOs) with fewer than 
4500 lines. 

Also in 1976, new processors became available to modernize the 
1ESS and 2ESS switches, doubling their call-carrying capacities. The 
1A ESS switch incorporates the 1A processor, which has a readable 
and writable memory. The 2B ESS switch is equipped with the 3A 
central control, which combines integrated circuit design with semi- 
conductor memory stores. 

The first local electronic switches replaced earlier, wired-logic elec- 
tromechanical systems such as the No. 1 and No. 5 crossbar and the 
still earlier step-by-step and panel progressive control systems. Stored 
program control led to greater flexibility in system design and reduced 
operations expenses in the telephone network. In early 1985, more 
than 3700 local electronic switching offices served more than 60 million 
lines worldwide. 

Because of the high cost of processors and their associated memories, 
by the mid-1970s electronic switches still could not economically 
replace the smallest electromechanical switching systems. Yet these 
offices, serving 2000 or fewer lines, accounted for approximately 60 
percent of the switching systems in the U.S. network. One response 
to this situation was remote switching. In 1979, the No. 10A Remote 
Switching System (RSS) (see Ref. 3) became available to connect 
these small offices to nearby host electronic switches by means of T- 
and N-carrier systems. 


- 1.2 Toll switching systems 


With the deployment in January 1976 of the first 4E.SS switch* in 
Chicago, fully digital electronic switching was introduced into the long 
distance network in the U.S. 

The 4ESS switch, a high-capacity, toll and tandem switching system, 
brought many major technical advances to the switching art. The most 
important change was the use of a time-division digital network in 
place of the space-division network. Because of the rapid growth in 
the number of digital transmission systems, the switching network of 
the 4ESS switch was specifically designed to pass Pulse Code Modu- 
lation (PCM) signals without conversion. Transmission and switching 
functions were more closely integrated than in any previous switching 
system. Economic considerations, such as significant reductions in 
installation, operating, and maintenance costs, played an important 
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part in the introduction of the 4ESS switch. By the end of 1984, more 
than 100 systems were serving both North American and international 
applications. These systems have a total of 3.3 million trunk termi- 
nations and carry more than 5 billion calls per month. 


1.3 Distributed systems 


Following the successful introduction of time-division digital switch- 
ing into the toll network, planning began for its application, with 
digital stored program control, in the local environment. Among the 
alternatives considered were adaptations of the 1A ESS switch and 
the 4ESS switch for local digital switching. Technology, however, was 
advancing rapidly in such areas as lower cost, more powerful micro- 
processors, and high-speed, fiber-optic communications systems. Such 
advances set the stage for a new generation of electronic switching 
with heavy emphasis on distributed network and distributed control. 
Thus, evolving technology and a strong market interest in digital 
systems led to the development of the 5ESS switch. 


Il. SYSTEM CHARACTERISTICS 


The 5ESS switch complements the earlier systems, which so suc- 
cessfully replace the larger electromechanical local and toll offices. For 
example, it can bring electronic switching to even the smallest local 
office. In addition, the 5ESS switch provides digital services and 
capabilities for an extensive range of applications. To these ends, the 
new switch was designed with seven major characteristics in mind:° 

1. The 5ESS switch is a single system with multiple applications 
(local, toll, operator services) that can cover the entire range of office 
sizes needed in telephone networks throughout the world. Table I 
shows a matrix of switching systems applied (as of 1983) across the 
metropolitan, suburban, and rural markets in the local, toll, and 
operator-services applications. The distributed control, modularity, and 
extensibility of the 5ESS switch allow it to serve all of these markets 
and applications. One consequence of this approach is the development 
of unified software to introduce new features throughout the family of 
5ESS switches without regard to application or size. Well-defined 
internal interfaces allow a flexible, modular approach for both hardware 
and software so the system can be economically configured to meet 
the special needs of each market segment. For example, in the area of 
PCM transmission, two different international standards (North 
American and European) exist. From the start, the basic architectural 
and timing parameters of the 5ESS switch were designed to be 
compatible with both standards. 

2. The 5ESS switch provides integrated interfaces between digital 
switching and transmission systems for both subscriber carrier systems 
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Table I—Switching systems used in metropolitan, suburban, and rural markets in 


local, toll, and operator-services applications 
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3ESS 5ESS 
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No: 4 ates by até locale } 5ESS 


Manual Traffic Service Position 
System/remote trunk 5ESS 
arrangement 





and interexchange circuits (24- and 30-channel systems). The 5ESS 
switch also has an efficient, easily maintained interface to analog 
interexchange circuits to simplify introducing the system into existing 
networks. Overall, the integration of functions will lead to a more 
rapid movement toward the integrated digital network and to the 
Integrated Services Digital Network (ISDN). 

3. The 5ESS switch permits the graceful incorporation of new 
technology as it becomes available. This objective is not new, of course. 
For example, just as the 1ESS and 2ESS switch processors were 
upgraded in the mid-1970s with new technology, the ferreed network 
was also replaced by the smaller and more economical remreed at 
about the same time. Similarly, since the system’s introduction in 
1976, virtually all the major units of the 4ESS electronic switch have 
been redesigned to take advantage of technological innovations.® These 
upgrades have pointed to the advantage of well-defined intermodule 
interfaces. Such interfaces become even more crucial as technology 
reduces the physical size of equipment and the replacement of units 
becomes important at the equipment bay level. The distributed nature 
and well-defined interfaces of the 5E.SS switch also allow easy replace- 
ment and evolution of selected components as market trends warrant. 
For example, the switching module processor has already been upgraded 
to raise call-handling capability above initial capacity. 

4. The modular design of the 5ESS switch allows increases in both 
network and processor capacity in reasonable, cost-effective increments. 
Earlier SPC switches had large growth modules. The resulting breakage 
penalty was as much as 5 to 10 percent of the switch price. To enable 
the system to be responsive to changes in forecasts and demographics, 
the design of the 5ESS switch allows for the addition or removal of 
equipment in operating exchanges and for conversion from one switch- 
ing application to another (e.g., from remote switch to stand-alone 
exchange). 

5. The 5ESS switch is highly reliable. Automatic fault detection, 
fault location, and reconfiguration capabilities ensure that faults can 
be identified, isolated, and repaired in a timely manner, thereby 
providing better service at lower maintenance cost. 

6. The 5ESS switch is designed for both local and centralized 
maintenance. The provision of centralized maintenance has been one 
major factor in the economic attractiveness of stored program control 
for growth and replacement of electromechanical systems. When both 
approaches are provided, local maintenance can be used when the first 
systems are introduced. Then, as the number of systems increases, 
telephone administrations can introduce compatible centralized 
maintenance systems to obtain additional economic benefits. 

7. The 5ESS switch allows new features to be introduced by means 
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of software. Techniques used in the 5ESS switch, such as a sophisticated 
operating system, a high-level language, and a modular design, make 
possible the rapid addition of features.’ In fact, the software environment 
is essentially the same among modules, enabling software to be ported 
among the various modules as architecture and feature needs evolve. 
Since maintenance routines constitute more than 50 percent of the 
system’s software, these routines are also designed to facilitate changes.® 
In addition, considerable effort has been expended on powerful off- 
line development systems and rigorous design methodologies® that 
have already proven effective during the initial applications of the 
5ESS switch’s software. They are expected to be increasingly valuable 
as the demand for services and features continues to grow, particularly 
in light of important new concepts, such as the evolving ISDN. 


lil. SESS SWITCH TECHNOLOGY, ARCHITECTURE, AND FEATURES 
3.1 Technology 


The technological sophistication of the 5ESS switch is apparent at 
every level of its design, from devices to architecture. Examples of 
state-of-the-art technology in the 5ESS switch include: 

1. Gated-Diode-Crosspoint (GDX) switch—a completely electronic 
(solid-state) line interface that reduces the space used by 60 percent 
over comparable interfaces and greatly improves reliability. 

2. Digital signal processor’°—a high-performance, high-density Very- 
Large-Scale Integration (VLSI) component that on one chip combines 
generation and detection of multiple tones with signal filtering, thereby 
reducing cost, space, and power requirements. This chip performs over 
1 million operations per second. 

3. Fiber optics—low-cost, high-capacity, internal communication 
links between modules that are resistant to electromagnetic interference. 

4, Distributed control—microprocessor-controlled switch modules 
that provide call-processing intelligence, and allow for system growth 
in modular increments and full feature capabilities at remote locations. 
These modules are coupled by a packetized control network that 
ensures reliable and efficient communication among all the elements 
of the system. 


3.2 Architecture 


The 5ESS switch has a modular, distributed architecture consisting 
of an administrative module, a communications module, and a number 
of switching modules (see Fig. 1). The communications module contains 
a message switch, which handles the packetized system control mes- 
sages, and a time-multiplexed switch, which interconnects switching 
modules with one another, as well as with the administrative module. 
Fiber-optic Network Control and Timing (NCT) links connect modules. 
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Fig. 1—Distributed architecture of the 5ESS switch. 


In the architecture of the 5ESS switch, those functions that are best 
done globally—such as administration, resource allocation, and 
maintenance access—are provided in the administrative module. Those 
needs that are best handled close to the external interfaces—such as 
most of the individual call handling, provision of network capacity, 
and terminations for lines and trunks—are distributed in the switching 
modules. Thus, the switching modules provide the major processing 
power in the system, performing over 95 percent of the per-call work. 
In addition, they form the basic growth unit and, as such, can be 
physically located either locally or at geographically remote sites. 

The design of the 5ESS switch will enable it to evolve to support 
Universal Information Services, a telecommunications industry goal 
that will enable network providers to offer their customers integrated 
transport, dynamic allocation of network resources, and adaptive, 
logically provided services. 


3.3 Features 


The flexible architecture of the 5ESS switch allows it to fulfill the 
needs of a spectrum of markets. For example, it provides basic and 
advanced subscriber services; toll and operator services; and extensive 
operations, administration, and maintenance features. Feature sets are 
being planned to take full advantage of the information-age capabilities 
of the ISDN. Table IT shows the planned capacity levels through 1985 
in terms of rated busy-hour calls, number of distributed switching 
modules, and line capacity. 


IV. STATUS 


The first multimodule 5ESS switch was put into service in August 
1983 at Sugar Grove, Illinois. The first local/toll 5ESS switch was cut 
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Table 1I—5ESS switch capacities through 1985 


Rated Maximum Number of Nominal Line 
Year Calls/Hour* Switching Modules Capacityt 
1983 130,000 30 50,000 
1984 200,000 48+ 50,000 
1985 300,000 - 192 100,000 


* Sustained operation, including customer features, all effective attempts, all messages 
billed, with no degradation of maintenance and administrative responsiveness. 

+ Allows for typical mixture of lines and trunks. 

+ Includes remote switching modules. 


over at Bradford, Pennsylvania, in October 1983. The remote switching 
module and integrated SLC® 96 carrier were cut over at Spotsylvania, 
Virginia, in April 1984. The first 5ESS switch with the international 
feature set was ready for service in Seoul, Republic of Korea, in Febru- 
ary 1985. 

The early thrust of the 5ESS switch has been small- to medium- 
size local and local/toll applications. In 1985, with the advent of the 
high-capacity enhancements and new features such as business and 
residence custom services, the application of the 5ESS switch will be 
expanded in both the North American and international markets. The 
early buildup of shipments of the 5ESS switch has been substantial. 
From just 183,000 lines shipped at the end of 1983, 5ESS switch line 
shipments grew by an additional 2.5 million in 1984, and more than 6 
million lines will be shipped in 1985. 


V. SUMMARY 


This paper has presented a general introduction to the 5ESS switch. 
Its distributed architecture, use of sophisticated digital technologies, 
and modular hardware and software design put the 5ESS switch at 
the leading edge of SPC switching systems. The papers that follow 
discuss the system in more detail. The first discusses applications 
planning” for the 5ESS switch. This is followed by papers on the 
overall architecture,’” the operational software,’ the maintenance soft- 
ware,’ the circuit-level hardware,’* the physical design of the hardware," 
and the software development system.’ The last set of papers addresses 
the first application and field experience,! the operations plan,’® and 
factory testing.” 
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The 5ESS Switching System: 


Applications Planning 
By W. R. BYRNE and G. P. O’REILLY* 


(Manuscript received December 8, 1983) 


The 5ESS™ system is designed for switching applications in rural, suburban, 
and metropolitan areas. It can function as a local, local/toll, or toll switch, 
and has features that make it suitable not only for use in the United States 
but in almost all countries. The modular design of the switch makes it 
particularly useful for solving wire center and network problems. This article 
discusses methods for solving such problems and presents some economic 
study results demonstrating the savings that can be achieved. 


I. INTRODUCTION 


The 5ESS system represents a major step in switching system 
architecture evolution.’ Using distributed control, modular hardware 
and software, and integrated electronics, the 5ESS system makes 
possible the integration of digital interoffice trunk facilities, digital 
carrier subscriber loop systems, and digital switching. Its modular 
- design provides remote switching systems for small office applications. 
An integrated operator service position system is planned to round 
out the complete set of switching features. 

Figure 1 gives a pictorial description of the various applications 
displayed over a large geographical area. The applications include 

1. Local office growth and modernization 

2. Access tandem, and operator services 

3. Toll office growth and modernization 

4. Small office modernization via remote switching 

5. New wire center via remote switching 


* Authors are employees of AT&T Bell Laboratories. 
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Fig. 1—5ESS switch applications. 


6. Integrated digital subscriber carrier systems 

7. Integrated interoffice facilities via digital carrier. 

Digital synergies between loop, switching, and interoffice transmission 
technologies are changing network planning methods.” Traditionally, 
the network planning process was perceived as a collection of related 
but essentially noninteracting disciplines, each of which was responsible 
for the evolution of a particular network function (subscriber network, 
local switching, interoffice facilities, toll switching, or operator services). 
As Fig. 2 illustrates, the communication among these disciplines was 
often limited to an exchange of completed plans. Such an exchange 
would ensure, for example, that a planned rehoming of an end office 
from one toll center to another was made known to those who were 
planning for the affected interoffice facilities. The process of developing 
the plan, however, was typically limited to a single discipline. 

Such an approach was justified in an environment where the 
network technology was characterized by well-defined boundaries among 
the various functions. However, the advent of integrated interfaces 
between switching systems and digital loop and trunk facilities has 
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Fig. 2—Traditional approach to planning process. 
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forced joint-area planning studies. Remote switching, which requires a 
host office for centralized administration, a change in trunk routing 
patterns, and oftentimes a change in interoffice facilities, necessitates 
further joint planning studies. Figure 3 gives a broad overview of the 
process by which two or more planning disciplines join together for a 
common study. It is important to point out that most often these 
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studies are made pairwise between disciplines, e.g., local switching and 
subscriber network, local switching and interoffice facilities, or toll 
switching and interoffice facilities. This process concentrates on the 
important interactions between disciplines, avoiding simultaneous study 
of all disciplines in great detail. The major elements in such a study 
include 

1. Recognizing the problems, formulating alternative solutions, and 
coordinating assumptions with related disciplines. 

2. Assessing which interactions (if any) are likely to be significant 

a. Performing a conventional, noninteractive study in those cases 
where no significant interactions are identified, or 

b. Performing interactive studies involving two or more disciplines 
as needed, where interactions do exist. 

3. Documenting the conclusions and obtaining project approvals, 
where all affected organizations give their concurrence to the resulting 
plan. 

Joint-area planning studies between disciplines have placed renewed 
emphasis on estimating total life-cycle costs of various network alter- 
natives over the planning horizon. Not only should the initial cost of 
equipment be considered, but ongoing growth costs, operations expenses, 
administration expenses, maintenance expenses, building additions, 
distributing frame expenses, rearrangement expenses, and revenue 
from potential new services all contribute to identifying and evaluating 
the best network solution. 

The remaining sections of this paper describe 5E.SS switch appli- 
cations in more detail. Section II covers the application of integrated 
subscriber carrier and interoffice facilities for a single wire center. 
Sections III and IV cover the applications and interactions involved 
in network area planning. Section V discusses the application of the 
5ESS system in metropolitan areas. 


il. WIRE CENTER AREA PLANNING USING THE 5ESS SWITCH 


As previously described, traditional local switching modernization 
studies were directed at comparing various switch replacement alter- 
natives for individual wire centers. The modeling boundaries separating 
the local switch from the subscriber loop and interoffice facilities 
studies are shown in Fig. 4. Important factors included in these wire 
center modernization studies were switching equipment. costs and 
capacities, maintenance costs, land and building costs, and feature 
availability. 


2.1 Integrated subscriber carrier system planning 


When modernization studies involve the 5ESS switch as a replace- 
ment alternative, additional factors must be considered. Consider Fig. 
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Fig. 5—Increased subscriber carrier penetration after modernization. 


4, which shows a comparison of nonintegrated and integrated switching 
and transmission interfaces. Figure 4a shows that the main components 
of a subscriber carrier system in a conventional (nonintegrated) 
interface with an analog switch include the Remote Terminal (RT),* 
Digital Line (DL), and Central Office Terminal (COT). In contrast, 
Fig. 4b shows that the need for COT's is eliminated when interfacing 
a digital subscriber carrier system (such as the SLC® 96 carrier) with 
the 5ESS system. The digital links from the RT terminate directly on 
a digital interface called the digital carrier line unit of the 5ESS 
system. This arrangement obviates the need for individual subscriber 
line terminations on the Main Distributing Frame (MDF) and line 
terminating equipment on the switch. 

Since the per-line termination cost of a subscriber carrier system is 
reduced when integrated with the 5ESS switch, application of such 
systems can be economically justified in more areas. The increased 
penetration of the subscriber carrier systems illustrated in Fig. 5, at 
the time of modernization, results in additional savings by avoiding 
cable expansions and related structure costs. (See Refs. 3 through 6 
for a detailed description of subscriber planning methods.) 

In summary, the incremental capital-savings-per-growth line realized 
through termination of subscriber carrier systems directly on the 5ESS 
switch versus termination on a central office without this capability is 
made up of the following five components: 

1. Analog line termination savings 

2. Reduced MDF termination costs 

3. Elimination of the COT 


* Acronyms and abbreviations used in the text are defined at the back of the Journal. 


1320 TECHNICAL JOURNAL, JULY-AUGUST 1985 


4, Reuse credit for the COTs displaced at the time of modernization 

5. Less distribution cable and structure (minus additional subscriber 
carrier electronics costs). 

In addition, opportunities for reducing maintenance costs arise as a 
result of eliminating the COTs and reducing MDF frame activity for 
those working lines served by an integrated digital subscriber carrier 
system. 


2.2 Integrated digital facility planning 


Similar opportunities for cost reductions exist when terminating 
digital carrier interoffice trunks directly on the 5ESS system. Referring 
again to Fig. 4, in the case of central offices with no integrated 
interface to digital facilities, digital carrier trunks terminate on digital 
channel banks and analog carrier trunks terminate on analog carrier 
banks. In the case of a 5ESS switch, analog trunks terminate via 
analog channel banks and the 5#SS trunk unit. For digital carrier 
trunks, the need to provide digital channel banks is eliminated 
and these trunks terminate directly on the Digital Line Trunk 
Unit (DLTU). 

Potential savings from digital carrier integration on the 5ESS 
system are a function of the facility strategy assumed at the time of 
modernization. The options include the following: 

1. Continue the planned analog and digital trunk penetrations 
regardless of replacement switch type. This is typical of traditional 
planning studies. 

2. Place all growth on digital facilities after the year of modernization 
but leave the existing analog plant in place. 

3. Place all growth on digital facilities and replace existing analog 
carrier facilities with digital carrier in the year of modernization. This 
is the most aggressive digital strategy. 

The major savings associated with integrated digital carrier on the 
5ESS system can now be summarized as follows: 

1. Switch termination savings, i.e., the lower cost of terminating 
trunks on a DLTU versus terminating trunks on an analog interface. 

2. Elimination of the need to buy digital channel banks for growth 
and the associated maintenance savings. 

3. Reuse of the existing digital channel banks at the time of 
modernization. 

4. Elimination of the need to purchase new analog carrier banks 
and the associated maintenance savings for facility strategies 2 and 3 
outlined above. In addition, maintenance of existing analog carrier 
banks is eliminated under strategy 3. 

Other considerations include reduced trunk testing costs associated 
with integrated digital carrier and additional rearrangement costs 
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incurred at the time of modernization for segregation of digital special- 
service circuits that are not integrated with the switch. 


2.3 An example wire center planning study 


As an example, consider a crossbar local/tandem switching system 
with the following characteristics: 

1. Size: 20,000 lines, 4000 trunks 

2. Growth per year: 1000 lines, 300 trunks 

3. Twenty-five percent of the growth lines are being placed on 
subscriber carrier systems each year to handle cable exhausts and 
subscriber line growth beyond 18,000 feet from the wire center. Ten 
percent of the lines are presently on the subscriber carrier. 

4, Fifty percent of the trunks are presently served by digital carrier 
and 50 percent by analog carrier. 

Consider replacing this entity with the 5ESS local/tandem system 
in 1985. We want to compare this with the Present Method of 
Operation (PMO), which involves growing and maintaining the existing 
equipment to meet the new demands. The cost of the PMO in terms 
of first cost, life-cycle costs, and revenue requirements is a useful 
reference for comparing alternative plans. 

The lower-cost integrated interfaces with digital subscriber carrier 
systems drop the subscriber carrier prove-in distance, after replacement, 
from 18,000 feet to approximately 12,000 feet from the wire center. 
Sixty percent of the new line growth demand can then be placed on 
subscriber carrier. Similarly, because of the integrated interface to 
digital carrier trunks, 100 percent of the new trunk growth is placed 
on digital facilities (strategy 2, discussed in Section 2.2). 

Figure 6 shows an economic comparison of the two alternatives. 
The modernization plan using the 5ESS switch is approximately 30 
percent less costly in terms of life-cycle costs. Note that the integrated 
interfaces account for almost 80 percent of the net savings when 
comparing these two plans. Additional revenues result from Custom 
Calling Services and enhanced Centrex service offerings. In the past, 
large-scale studies performed by AT&T with the Operating Telephone 
Companies (OTCs) showed the switching/transmission synergies to be 
significant. In particular, South Central Bell developed a company- 
wide modernization plan for 240 step-by-step and crossbar entities in 
their regions.’ The overall results showed that 16 percent of the total 
network savings were attributable to these synergies. The effect of the 
digital synergies is largely a function of the subscriber carrier and 
interoffice facility digital strategies. 


2.4 New wire center planning using the remote switching module 


The Remote Switching Module (RSM) is a 5ESS switch module 
that is geographically separated from a host 5ESS switch. The RSM 
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Fig. 6—Twenty-year life-cycle analysis. 


module is linked to the host 5ESS switch via digital carrier facilities. 
Reference 1 discusses the architecture of the RSM. The RSM is an 
ideal candidate for new wire centers and replacement of small step- 
by-step or crossbar switches. 

When used to switch lines alone, the RSM can currently serve up 
to 4000 lines. Later in 1985, this capacity will be increased to 12,000 
lines. It is possible to switch all traffic not contained completely within 
the RSM through the host 5ESS switch. This approach is economical 
for small wire centers with small amounts of traffic to neighboring 
centers. The cost of the longer transmission path through the host is 
balanced by the higher traffic efficiency of larger trunk groups, and 
the elimination of trunk administration and maintenance costs at the 
RSM site. 

However, an RSM can interface with analog and digital lines and 
trunks in the same way as a 5ESS switch. Terminating analog or 
digital trunks on an RSM is often important for small offices offering 
Extended Area Service (EAS), where large volumes of interoffice traffic 
justify direct trunk groups to many adjacent class 5 offices. 
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Integrated digital subscriber carrier is also an important feature of 
an RSM. Subscriber carrier systems are more widely used in the 
remote locations for which RSMs will often be considered. 

The RSM brings to the small office market all of the features 
offered by the 5ESS switch, including new business and residence 
features. The RSM offers the wire center planner the following 
benefits: 

1. The RSM can share the office code (NNX code) of the host 
office. 

2. The RSM is administered and maintained centrally through the 
host switch. This reduces the staff requirements at the remote wire 
center. 

3. The RSM architecture can grow from a single-switch module 
(serving up to 4000 lines) to a larger remote system with multiple- 
switch modules (serving 12,000 or more lines). 

4. The RSM can grow into a 5ESS switch by adding an adminis- 
trative module and a communications module. 

5. A 5ESS switch can be converted to an RSM if a second 5ESS 
switch is located within hosting range (approximately 100 miles, 
depending on transmission media). 

The application of the RSM to a small but rapidly growing community 
is illustrated in Fig. 7. 


Ill. NETWORK PLANNING USING THE 5ESS SYSTEM 


As discussed in Section II, the 5ESS switch, coupled with digital 
subscriber carrier systems and digital interoffice facilities, provides 
new solutions to wire center evolution problems. The advantages of 
the 5ESS switch are equally effective for those planning the evolution 
of a network® of local switches, tandem and toll switches, new wire 
centers, operator services, and the operations systems and centers that 
administer and maintain the network. 

The principal benefits that the 5ESS system offers to network 
planners are the following: 

1. Remote switching. The RSM is a low-cost alternative to small 
office modernization that offers all the revenue potential of a 5ESS 
switch. Because RSMs are monitored and administered through a host 
switch, the operation expenses of RSMs are much lower than stand- 
alone switches. j 

2. A remote switch that can grow into a 5ESS switch. This keeps 
the getting-started cost low for small offices with a high growth 
potential. It provides the planner with a switch that can grow into a 
stand-alone switch when growth actually occurs, and provides safeguards 
for areas where growth rates turn out lower than expected. 

3. An integrated Operator Service Position System (OSPS). The 
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Fig. 7—-Application of a remote switching module to a new wire center. 


presence of OSPS will allow modernization and expansion of operator 
services when tandem and toll offices are considered for modernization. 
Since OSPS will be fully integrated into the toll and tandem 5ESS 
switch, Operations, Administration, and Maintenance (OA&M) costs 
are reduced compared to a stand-alone operator system. 

4. An integrated digital subscriber carrier (SLC 96 carrier) interface. 
This lowers the cost of deploying pair gain systems and provides an 
inexpensive solution to cable exhaust problems. In addition, several 
integrated subscriber carrier systems can be used to modernize very 
small Community Dial Offices (CDOs). 

5. An integrated interface to digital carrier facilities. This lowers 
the cost of upgrading Voice-Frequency (VF) and analog carrier systems 
to a digital carrier. 

6. Tandem and toll capabilities that allow the switch to serve as a 
combined local/tandem, pure tandem, or pure toll switch. 

7. Remote toll and tandem switching capability. The RSM can be 
used as a small toll or tandem switch to serve inter-LATA (Local 
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Fig. 8—A sample network planning problem. 


Access and Transport Areas) or intra-LATA traffic in those areas 
where a stand-alone toll switch cannot be economically justified. 

8. Integrated Services Digital Network (ISDN) capabilities. Inte- 
grated digital interfaces to digital loop and digital trunk facilities are 
leading to an integrated digital network. End-to-end digital services 
are being added to the network, providing new voice and data service 
revenues to the telephone companies. 

The complexity of a network planning study varies with the size of 
the network being considered and functions included in the plan (e.g., 
operator services or tandem switches.). Such a study can be as small 
as a network of two or three interconnected switches or as large as 
the entire telecommunication network for a large city. To illustrate 
the application of the 5ESS system to network planning, consider the 
network shown in Fig. 8. Assume that a group of OTC network 
planners have the responsibility of planning the evolution of this intra- 
LATA network and have the following objectives: 
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1. Modernize the entire network to provide new revenue-producing 
services to existing residence and business customers. 

2. Introduce operator services into the exchange network. 

3. Provide up-to-date business services to the new office park and 
factory. 

4, Minimize the cost of the projected feeder cable exhaust in 1986. 

5. Reduce OA&M costs. 

6. Keep the economic impact on the rate payer (revenue require- 
ments) as low as possible. 

The network planner is faced with many possible approaches to the 
network problems in terms of network products and the timing of the 
network evolution steps. Typically, the network planners must examine 
many solutions to find the one that comes closest to satisfying all of 
the objectives. As discussed previously, one plan included in most 
network studies is the PMO. Although few of the planning objectives 
can be met with the PMO, the cost of the PMO is included for 
reference. One solution the planner might consider is shown in Fig. 9. 
The network is modernized over six years as follows: 

1985 
. Replace the crossbar at office A with a new digital switch. 

. Lay a new feeder cable to office A. 

. Add a new operator service system. 

. Upgrade the facility between A and C to digital. 

. Add digital carrier banks at office C. 

. Establish a new wire center and switch at the office park. 

. Expand the operation center to support the new wire center 
and operator system. 

1987 

1. Replace the step-by-step at office C with a digital switch. 

2. Remove digital carrier facilities from office C and reuse at 

office B. 

3. Convert the VF facility between B and C to digital. 

4. Expand the feeder cable to the new factory. 

1990 

1. Replace the 2000-line CDO at office B. 

2. Remove digital channel banks. 
Note that two feeder routes had to be expanded, the CDO at office B 
was too small to justify replacement until 1990, and the operation 
support centers and systems had to be expanded to support the new 
operator system and the wire center at the office park. 

One possible approach using the 5ESS system is shown in Fig. 10. 
The network is modernized over three years as described below: 

1985 

1. Replace crossbar at office A with a 5ESS switch. 
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Fig. 9—Network plan 1. 


2. Upgrade the facility between office A and C to digital. 
3. Replace step-by-step at office C with an RSM (begin collecting 
new service revenues). 
4. Replace CDO at B with an RSM (begin collecting new service 
revenues). 
5. Upgrade the facility between B and C to digital. 
6. Add RSM in the office park. 
7. Reduce operation center staff due to consolidation of operations 
support of offices B and C at office A. 

1986 


1. Deploy integrated SLC 96 carrier from office A to avoid feeder 
exhaust. 
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Fig. 10—Network plan 2—applying the 5ESS switch. 


1987 
1. Deploy integrated SLC 96 carrier at the new factor to avoid 


feeder cable expansion. 
2. Expand 5ESS switch at office A to include operator function. 
All offices are replaced in 1985 to achieve maximum new revenue 
potential and to avoid unnecessary purchases of nonintegrated digital 
channel banks. If capital constraints in 1985 prevent modernization of 
all offices in one year, offices B and C could be scheduled in later 
years. Since the RSMs in B, C, and D, as well as the operator system 
at A, are operated and administered through the 5ESS switch at A, 
the load on operation center staff and the operations support systems 
will be reduced. Feeder exhausts in 1986 and 1987 are avoided by 
using integrated subscriber carrier systems. The 5ESS system allows 
all business features to be extended over the subscriber carrier lines 
to the new factory location. Note that the RSM at offices B and C 
can either continue to direct trunk the EAS traffic or route traffic 


through the host 5ESS switch. 
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To evaluate the alternative network evolution planning strategies, 
it is necessary to use life-cycle economic techniques together with 
annual capital constraints. A first-cost analysis could point to solutions 
that in the long term are far from optimum. As an example, Fig. 11 
shows an economic comparison of the three alternatives considered. 
The 5ESS system alternative is the least costly alternative over the 
study period. While the switching capital is greater than the PMO, 
the plan realizes more new service revenues from the earlier modern- 
ization of the offices, and significantly lower maintenance and admin- 
istration expenses. The 5ESS system plan also avoids the capital cost 
associated with feeder route expansions. Note that the first plan with 
all stand-alone digital switches is not economically preferable to 
the PMO. 


IV. OTHER NETWORK APPLICATIONS 


In addition to solving local network problems as illustrated in 
Section III, the 5E.SS switch can be used in pure toll networks and to 
implement an access tandem network. 
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4.1 Toll networks 


Toll switches are used by Interexchange Carriers (ICs) to transport 
traffic between LATAs. The 5ESS switch with its complement of toll 
features and its distributed architecture can provide new solutions to 
toll switching network problems. As an example, consider the network 
shown in Fig. 12. As a result of the Bell System divestiture, communities 
A and B fell on different sides of a LATA boundary. An IC is therefore 
required to provide service between them, according to divestiture 
rulings, and is leasing toll switching capacity and facilities from local 
exchange companies. Communities A and B are forecasted for continued 
growth and the local/toll switch is planned for replacement by the 
local exchange company. The IC wishes to establish a separate toll 
switch to handle larger forecasted toll traffic volumes. However, current 
traffic levels do not justify a large switch. An RSM serving as a small 
toll switch is a good candidate and is shown in Fig. 13. This need for 
small toll switches is common along LATA boundaries and along 
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Fig. 13—Applying the 5ESS switch to an inter-LATA network. 


international boundaries where nearby towns have strong communities 
of interest but lie in different toll areas. 


4.2 Tandem networks 


A primary need of telephone companies in the postdivestiture 
environment is for access tandem switches. These switches serve as 
an interface between the local switches and ICs. Access tandems 
concentrate the interexchange calls from local offices and route these 
calls to the proper IC. Consider the network shown in Fig. 14. Today 
the network consists of six local switches, each having toll trunks to 
a digital toll switch owned by IC,. IC, through ICy also wish to 
provide service. The telephone company can put in trunks from each 
local switch to each IC or it can establish an access tandem network. 
Unless the traffic between each local switch and IC is initially large, 
direct trunk groups are difficult to justify economically. Indeed, if the 
traffic to the ICs—other than IC,—is small but growing, significant 
savings can be realized by sending this traffic to a tandem where all 
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the traffic for ICs is consolidated and then trunked. In our example, 
we will replace office C with a 5ESS switch and establish it as an 
access tandem. In addition, we will replace the small CDO at office E 
with an RSM and it too can serve as an access tandem. The result is 
shown in Fig. 15. 

Note that some of the larger local offices shown will continue to 
trunk traffic to IC, over direct groups, since the amount of traffic can 
justify direct trunking. All local switches, however, use the 5ESS 
switch (directly or via the RSM) to access IC, through ICy. In fact, 
some of the smaller offices now use the access tandem to route traffic 
to the digital toll switch of IC,. This solution saves significant facility 
costs, helps modernize the local switches, and provides for an efficient 
tandem switching structure that can flexibly accommodate uncertain, 
yet growing, IC traffic demands. 
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Fig. 15—Applying the 5ESS switch to access tandem network. 
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Fig. 16—Digital access networks. 


V. MODERNIZING METROPOLITAN AREAS 


Many metropolitan areas are dominated by the presence of the 
1ESS™ and 1A ESS systems, which have replaced most of the large 
electromechanical offices in these areas. These are advanced stored 
program control switches with a rich set of business features. One 
might be led to conclude that the application of the 5ESS switch to 
these areas will consist of completing the replacement of the remaining 
electromechanical switches. However, the following are two additional 
types of application for which the 5ESS system is ideally suited: 

1. Deployment of digital access networks 

2. 1ESS system replacement. 


5.1 Digital access networks 


A digital access network is an overlay network consisting of the 
5ESS system, digital loops, and digital remote switches. Figure 16 
illustrates the concept. The objective is to locate new technology where 
it is needed, to provide ubiquitous access to digital networks for any 
customer in the area, and to provide a cost-effective and minimum- 
capital solution without requiring the replacement of Stored Program 
Control (SPC) technology. 

This technique may become more popular in the future with the 
development of optical remote modules, where fiber lightguide inter- 
connects the hosts and remotes and where fiber is extended into the 
loop plant with such systems as Fiber SLC 96 carrier. The trend in 
some metropolitan areas is towards fiber backbone routes and fiber 
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Fig. 17—ISDN access arrangements. 


rings. This trend coupled with optical remote switches will accelerate 
the deployment of digital access networks. 

The initial applications of the 5ESS switch will be replacements of 
those electromechanical systems that are colocated with other SPC 
switches. Rather than replacing them by consolidation with the 
SPC switch, the 5ESS switch technology can be placed in the existing 
SPC wire center. From here the digital access network will begin. 


5.2 1ESS system replacement 


Many 1ESS systems are relatively small, but are experiencing 
growth. They demand new features and capabilities available only on 
the 1A ESS system or new time-division digital systems like the 5ESS 
switch. In these instances, with high subscriber carrier penetration, 
and the ability to reuse the line and trunk link networks of the LESS 
system, the replacement of the 1ESS system can be economically 
justified. 
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5.3 Evolving the network towards ISDN 


The 5ESS system, with its integrated digital interfaces to subscriber 
carrier systems and to digital carrier trunks, is helping to lead the way 
to an ISDN where there are no analog to digital conversions. When 
end-to-end digital services are added to this network, the ISDN can 
be realized. ISDN interface standards are being defined by the Inter- 
national Telegraph and Telephone Consultative Committee (CCITT) 
and by the Exchange Carrier Standards Association. Figure 17 shows 
the potential access arrangements for Digital Subscriber Lines (DSLs), 
extended DSLs to digital private automated branch exchanges, and 
multiplexed DSLs over integrated subscriber carrier systems. Current 
5ESS switch plans call for development of ISDN capabilities that 
incorporate both circuit switching for voice traffic and packet switching 
for data traffic. These capabilities will lead the way to simultaneous 
voice and data applications across the network, accelerating the trend 
towards end-to-end digital networks and services. 


VI. CONCLUSION 


This paper demonstrates that the 5ESS switching system provides 
planners with the major building blocks needed to evolve today’s 
network into a digital network offering end-to-end digital services. 
The modularity of the 5ESS system design, coupled with the ability 
to distribute control to remote switching modules, offers new low-cost 
solutions to long-standing network problems (e.g., small office modern- 
ization). It provides new ways to affect the evolution of the entire 
telecommunications network (e.g., local switching network, access 
tandem networks, interexchange carrier network, operator services). 
Low-cost interfaces between the 5ESS switch and digital loop systems 
and digital transmission facilities allow network planners to convert 
the network from analog to digital gracefully. 


REFERENCES 


1. D. L. Carney et al., “The 5ESS Switching System: Architectural Overview,” AT&T 
Tech. J., this issue. 

2. W. M. Ohnsorg, “Overview of Planning for the Application of New SPC Switching 
Technology in the Bell System,’’ Nat. Telecommun. Conf., Washington, D.C., 
1979. 

. B. Bulcha et al., “Feeder Planning Methods for Digital Loop Carrier,” B.S.T.J., 61, 
No. 9 (November 1982) pp. 2129-41. 

. B. Bulcha et al., “An Area Planning Methodology for Wire Centers,” Nat. Telecommun. 
Conf., Washington, D.C., 1980. 

. A. J. Ciesielka, D. H. Morgen, and G. P. O’Reilly, “Planning for the Integrated 
Local Digital Wire Center,” Nat. Telecommun. Conf., Washington, D.C., 1979. 

. A. J. Ciesielka and D. C. Douglas, “Electronics in the Suburban and Light Urban 
Loop Networks, B.S.T.J., 59, No. 3 (March 1980), pp. 417-39. 

. H. E. Gray, G. P. O’Reilly, and M. J. Stefanik, “Planning Methodology for the 
Introduction of Local Time Division Digital Switching,” Int. Switching Symp., 
Montreal, Canada, 1981. 


I om ao - w 


1336 TECHNICAL JOURNAL, JULY-AUGUST 1985 


8. B. H. Fetz et al., “Planning for Rural Modernization,” Bell Lab. Rec., 58, No. 2 
(February 1980) pp. 55-62. 


AUTHORS 


William R. Byrne, B.S. (Electrical Engineering), 1970, Manhattan College; 
M.S. (Electrical Engineering), 1971, Columbia University; AT&T Bell Labo- 
ratories, 1970—. Mr. Byrne’s responsibilities have included system specifications 
for the AMPS mobile phone switch, system design of the 1A Voice Storage 
System, generic planning for the 1A ESS switch, operations planning and 
feature planning for the 5ESS switch, local switching market assessment and 
market forecasting, new switching technology assessment, and switching system 
evolution planning. He is currently a Supervisor in the System Study Depart- 
ment. Member, Tau Beta Pi, IEEE. 


Gerard P. O’Reilly, B.S. (Mathematics), 1969, Manhattan College; M.S. 
(Operations Research), 1971, Columbia University; Eng.Sc.D. (Operations 
Research), 1975, Columbia University; AT&T Bell Laboratories, 1969—. Mr. 
O’Reilly began his AT&T career at New York Telephone as a telephone 
station repairer. In 1969, he joined Bell Laboratories as a member of the Local 
Switching Systems Engineering Department. In 1977, he was transferred and 
promoted to Supervisor in AT&T’s Local Network Planning Group. In 1978, 
Mr. O’Reilly returned to Bell Laboratories as Supervisor of the Local Switching 
Planning Automation Group. In 1981, he supervised a group responsible for 
planning the evolution of the 5ESS switch. In 1983, he assumed his present 
position: Supervisor, Switching Services Strategic Planning Group. His group 
does strategic planning for new switching services. Member, IEEE, Sigma 
Xi, Operations Research Society of America, the American Statistical Asso- 
ciation. 


APPLICATIONS PLANNING 1337 


AT&T Technical Journal 
Vol. 64, No. 6, July-August 1985 
Printed in U.S.A. 


The 5ESS Switching System: 


Architectural Overview 


By D. L. CARNEY,* J. 1. COCHRANE,” L. J. GITTEN,' E. M. PRELL,* 
and R. STAEHLER* 


(Manuscript received December 12, 1983) 


This paper presents an overview of the 5ESS™ system architecture. The 
administrative, communications, and switching modules are described, together 
with an overall view of the software architecture. Operations and maintenance 
aspects and a short discussion of evolutionary trends are covered. 


I. 5ESS SYSTEM ARCHITECTURE 


The 5ESS system architecture was conceived to satisfy the goals 
set forth in the introductory paper.’ This architecture incorporates a 
combination of distributed and centralized control to produce a robust 
system that will meet present and future switching needs. 

The hardware architecture, shown in Fig. 1, has three major com- 
ponents: 

e An Administrative Module (AM),? which provides systemwide 

administration, maintenance, and resource allocation. 

e A Communications Module (CM), which provides a hub for 
distributing and switching voice or digital data, control infor- 
mation, and synchronization signals. 

e One or more Switching Modules (SMs), which provide local 
switching and control functions, and the interface to subscriber 
lines and interexchange circuits. 
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Fig. 1—5ESS system distributed architecture. 


The following sections describe the functions of these subsystems 
and their interrelationships. In addition, they discuss the Remote 
Switching Module (RSM) and the subscriber carrier system. 


1.1 Administrative module 


The AM provides the system-level interfaces required to operate, 
administer, and maintain the 5ESS switch. It performs functions that 
can most economically be done globally, such as common resource 
allocation and maintenance control (see Fig. 2). For reliability the 
Administrative Processor (AP), currently an AT&T 3B20D computer 
(see Ref. 2), is fully duplicated, and the two processors work in an 
active/standby configuration. In normal operation the active processor 
has control and, at the same time, keeps the data in the standby up 
to date. Thus, when a fault occurs in the active processor, the standby 
is switched into service with no loss of data. 

The AM performs many call-processing support functions, including 
systemwide craft maintenance access, diagnostic and exercise control 
and scheduling, software recovery and initialization, and certain fault- 
recovery and error-detection functions best done on a centralized basis. 
Within the AM there is error-checking circuitry for detecting and 
isolating faults. The AM also performs administrative functions and 
provides software access to external data links and to disk storage. 

Today the call-processing functions of the AM consist of routing 
and resource allocation. Routing involves the determination of the SM 
on which the terminating line or trunk appears and the selection of 
an available trunk in a trunk group. The AM also allocates and 
releases global resources, such as Time-Multiplexed-Switch (TMS) 
time slots. 


1340 TECHNICAL JOURNAL, JULY-AUGUST 1985 












ADMINISTRATIVE MODULE 
AT&T 3B20D 
PROCESSOR | 







DATA LINKS FOR e 
CENTRALIZED e 
OPERATIONS 





1/0 r | 
PROCESSOR 


COMMUNICATIONS 
MODULE 


Fig. 2—Administrative module. 





A disk memory provides flexible mass storage for programs and 
data. When needed, these programs and data are transferred to the 
main memory in the AP or to the memories in the SMs. In the 
unlikely event of a duplex system failure, the disk also provides rapid 
program and fixed-data recovery, as well as retention of billing data. 

The I/O Processor (IOP) is a subunit of the AM. It is equipped 
with a scanner/signal distributor, which accommodates functions such 
as major building and office alarms. Interfaces with operations support 
systems, video display units, hard copy printers, magnetic tape drives, 
and a Master Control Center (MCC) are also provided through 
the IOP. 

The MCC provides the human-machine interface for the 5ESS 
switch. This includes displaying the system status and providing 
manual control over system operations. Telephone companies have 
the option of using (1) a language similar to that used in the 1A ESS™ 
system or (2) the new International Telegraph and Telephone Con- 
sultative Committee (CCITT) standard craft interface language (MML). 
The craft interface also supports an extensive color graphics display 
of system unit status as well as a menu-based command and control 
language. 


7.2 Communications module 


The basic function of the CM is to provide consistent communication 
between the SMs, and between the AM and the SMs. The Message 
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Fig. 3—Communications module. 


Switch (MSGS) transfers call-processing and administrative messages 
between the SMs and the AM, and between any two SMs (see Fig. 3). 
The MSGS performs a packet-switching function within the 5ESS 
switch utilizing CCITT X.25 level-2 protocol to transfer control 
messages through the CM and its terminating Network Control and 
Timing (NCT) links. This protocol includes error detection, positive 
message acknowledgment, and message retransmission in the event of 
a transmission error. An MSGS can support a combined total of 48 
SMs and RSMs. A current development will allow the MSGS to grow 
and support nearly 200 SMs. 

The message interface and clock unit also provides the clock that 
synchronizes the time-division network. This clock can be synchronized 
through an external source or run on an internal reference basis with 
periodic updating. The 5ESS switching network uses a time-space- 
time architecture. As illustrated in Fig. 4, a Time-Slot Interchange 
Unit (TSIU) in each SM performs the time-division switching; the 
TMS in the CM performs the time-shared space-division switching. 
At each interface unit the outputs from lines and trunks are converted 
into 16-bit time slots. These bits are used for signaling, control, and 
parity, and for binary-coded voice or data. The time slots are switched 
through the Time-Slot Interchanger (TSI) and time multiplexed into 
NCT links of the TMS. 

The TMS is a single-stage switching network that provides the 
digital paths for switched connections between the modules and for 
control messages among modules. The TMS interconnects the modules 
through the NCT links. 
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Fig. 4—Switching module. 


The NCT links use fiber lightguides. This new technology offers 
high-data-rate capacity and simple interconnection to switching 
modules. Compared with conventional cables, the fiber lightguide 
requires substantially fewer cables to interconnect the various units in 
the system, simplifying growth procedures. System reconfiguration 
equipment for maintenance is also reduced. Further, the fiber lightguides 
are not susceptible to electromagnetic interference and do not create 
electrical noise. 

Each NCT link carries 256 channels (time slots) of multiplexed data 
in a 32.768-Mb/s serial bit stream. One of the time slots carries control 
messages, and the remaining 255 time slots carry digitized voice or 
data. Additional voice/data time slots can be temporarily assigned to 
the control function in order to transfer large amounts of data. Two 
NCT links are associated with each module, thus allowing 512 time 
slots to be routed to and from the TMS. Setting up a path between a 
line or trunk on two SMs involves finding an idle time slot on one of 
the NCT links to each SM. A path is then set up through the TMS 
between these two NCT links on the selected time slot. The TSIU in 
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each SM will establish a path between the chosen NCT time slot and 
the peripheral time slot associated with the line or trunk. 


1.3 Switching module 


SMs provide call-processing intelligence, the first stage of switching 
network, and line and trunk terminals. As a result, the SM is the 
primary growth unit of the 5ESS switch (see Fig. 4). 

SMs may differ in the types and quantities of interface equipment 
they contain, depending upon the characteristics of the lines or trunks 
terminating thereon. Certain equipment is, however, common to all 
SMs. The common equipment includes a pair of dual-link interfaces, 
duplicated module processor units, duplicated TSIUs, and a digital 
services unit. The dual-link interface provides a two-way interface 
between each SM and the TMS in the CM. The duplicated Module 
Processors (MPs) control call processing, call distribution, and mainte- 
nance functions. 

The TSIU contains a signal processor, which handles address and 
signaling information, and a control interface, which distributes control 
signals to and from the interface. The TSIU switches time slots 
between the interface units in an SM and connects time slots from 
the interface unit to time slots on NCT links. The TSI switches 512 
time slots—256 from each of the active NCT links—and 512 peripheral 
time slots from the interface units. The TSI can connect any of its 
512 peripheral time slots to any other peripheral time slot, or to any 
time slot of either NCT link to the TMS. A local digital services unit 
provides tone decoding and tone generation capabilities. 

A variety of interface units are available in the 5ESS system. Line 
units (LUs) provide interfaces to analog lines. Trunk Units (TUs) 
provide interfaces to analog trunks. Digital Line Trunk Units (DLTUs) 
provide interfaces to digital trunks and remote SMs, while Digital 
Carrier Line Units (DCLUs) provide the interface to remote subscriber 
loop carrier systems. Each SM can accommodate any mixture of these 
units, with up to 510 channels. Two time slots are used for control. 

The LU terminates all of the facilities that are typically categorized 
as lines, including coin lines and private automatic branch exchange 
lines. Each terminal can be used for any type of line. 

The connection of a line to the 5ESS system requires the BORSCHT 
functions: battery feed, overvoltage protection, ringing, supervision, 
(digital) coding and decoding, hybrid, and testing. Ringing and test 
functions are provided by high-level service circuits. Channel circuits, 
which are shared through a concentrator, provide the other BORSCHT 
functions. 

A concentrator, using a solid-state crosspoint network, connects the 
line terminations and the channel circuits. The crosspoint network 
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consists of newly developed Gated Diode Crosspoints (GDXs) that can 
withstand the high voltage required for ringing and line testing. As a 
result, all connections are made electronically, without the use of 
relays. The concentrator can be provided at 8:1, 6:1, and 4:1 concen- 
tration ratios. The concentration ratio can be changed by simply 
adding or removing plug-in units. These ratios can be mixed within 
an office if needed. An LU can serve a maximum of 512 lines with an 
8:1 concentration ratio. 

The TU terminates interoffice trunks, and trunks to operators and 
to announcement circuits. A TU has 64 data channels and terminates 
up to 64 voice frequency trunks (that is, trunk traffic is not concen- 
trated). The circuits in a TU are divided into two general categories: 
trunk circuits and common circuits. Each trunk has an associated 
trunk circuit, which includes digital coding and decoding, dc signaling, 
and test access functions. Common circuits are associated with groups 
of 32 trunks. The functions performed by these circuits include testing, 
alarming, and multiplexing. 

The DLTU provides direct interfacing with digital facilities using 
1544-kb/s (24-channel) or 2048-kb/s (30+2-channel) pulse code mod- 
ulation transmission. A DLTU may terminate up to ten 1544-kb/s 
digital lines or sixteen 2048-kb/s digital lines. 

A DLTU contains a number of Digital Facility Interfaces (DFIs). 
The DFI is the interface between the digital transmission facility and 
the 5ESS switch. Like an analog line or TU, each DFI interfaces to 
each TSIU by means of peripheral interface control and data buses. 
The DFI aligns frames; detects alarms, framing errors, and slips; and 
notifies the module processor when a trouble condition or error 
threshold is reached. 


1.4 Remote switching module 


The 5ESS system can serve remote customers with the same 
features and services provided to local customers. This capability is 
provided by the RSM, which can be located as far as 150 kilometers 
from the host exchange, while still meeting transmission objectives 
(see Fig. 5). The RSM consists of standard SM hardware augmented 
by circuits to terminate the digital facilities that connect it to the host 
exchange. The NCT links at the RSM are converted to T1 data format 
and transmitted across T1 facilities that terminate on an SM at the 
host location. The RSM can provide service to a maximum of 4096 
lines with a concentration ration of 8:1. 

The number of equipped digital lines between the RSM and its host 
is primarily determined by traffic characteristics. A minimum of two 
digital lines is presently recommended to provide reliable transport to 
the host. A maximum of either twenty 1544-kb/s lines with 24 channels 
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Fig. 5—Remote switching module. 


or sixteen 2048-kb/s lines with 30 channels can be utilized to serve 
traffic between the host exchange and the remote site. 

During the normal mode of operation, the RSM is connected by 
control and data links to its host system. Direct trunks to other offices 
are also supported. In the rare event of a total transmission failure, 
the RSM can process calls to lines directly connected to it and over 
the direct trunks. This processing is called stand-alone operation. 

During the transition to or from stand-alone operation, intra-RSM 
calls will be maintained to minimize call cutoffs. Normal dialing 
patterns will be accepted. When it is not possible to process a request 
(because the call is destined for lines reached through the host or 
because features require host resources not available at the RSM), 
the subscriber will be connected to reorder tone or to a recorded an- 
nouncement. 

In stand-alone operation, the RSM provides access to emergency 
services, such as police, that normally would be accessed through the 
host. This provision is implemented independently of the normal links 
between the RSM and its host. 


1.5 Subscriber loop carrier system 


The SLC® 96 carrier system is a digital loop carrier pair gain 
system’ designed as a supplement or replacement for cable. The SLC 
system serves up to 96 subscribers over T1 transmission facilities. 

The 5ESS switch provides a digital interface to the SLC 96 system 
either from an RSM or directly from a local SM. A mechanism for 
performing spare digital line switching is available in either arrange- 
ment. The direct interface between SLC 96 system remote terminals 
and the 5ESS switch is provided by the DCLU. 


Il. 5ESS SOFTWARE ARCHITECTURE 
2.1 Software design strategies 


For a large software system such as the 5ESS switch, with its 
stringent requirements for performance, reliability, maintainability, 
extensibility, and life-span, it is of paramount importance to define a 
modular software architecture that exhibits unity of design. The 
structural integrity of such a software architecture can be preserved 
by establishing a set of strategies and then using them as guiding 
principles throughout the design of the software architecture, as well 
as during the entire life of the system. The most important strategies 
used in the definition of the 5ESS software architecture are as follows: 

1. Hierarchy of virtual machines—The concept of structuring the 
software as a set of layers (levels) of abstraction, each defining a 
virtual (abstract) machine, has been employed in the design of 5ESS 
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software architecture. The resulting software structure takes the form 
of a hierarchy of nested virtual machines. 

2. Software modularity—The software implementing each virtual 
machine is in turn partitioned into modules. A software module is a 
functionally coherent unit with well-defined interfaces, whose imple- 
mentation is hidden from all other modules. The changes to its 
implementation algorithm are transparent to all modules using it. 

3. Module portability—The software modules are coded in a high- 
level language, permitting the object code to run on a variety of target 
processors. Combining this with the other aspects of the software 
structure allows modules to be moved among the many system proces- 
sors (e.g., AP to MP) in order to optimize performance. 

4, Distribution of control and data—The distribution of both control 
and data represents a major software design strategy for implementing 
the distributed architecture of the 5ESS switch. Functions and their 
related data are distributed among the modules providing terminal 
services (e.g., SMs) and modules providing global services (e.g., 
the AM). 

5. Loosely coupled network—Another important strategy is the 
design of the 5ESS switch as a network of loosely coupled modules 
connected via data links. The processor in each module has its own 
view of the network and functions consistently with that view. Although 
loosely coupled, the interfaces among modules are well defined. 


2.2 An overview of the software architecture 


The 5ESS software architecture is defined as a hierarchy of nested 
virtual (also called abstract or logical) machines that spans all proces- 
sors. The hierarchy is made of a number of virtual machines structured 
as sequential layers, each using the services of the lower machines and 
providing additional services for the higher machines. This hierarchy 
is general, in the sense that a given machine can use the services of 
any lower machine, not just those of the machine immediately below 
it. When this view is extended to the entire system, the hardware can 
be represented as yet another layer at the bottom of the hierarchy, 
called the physical machine. This layer consists of the processors with 
their peripherals and is traditionally referred to as the “bare machine” 
(see Fig. 6). 

Most of this software is written in the high-level language C. There 
are several types of processors controlling each physical module. These 
include customized microprocessors, an MC68000 chip,* and an AT&T 
Technologies Digital Signal Processor in the SM, an 8086 in the CM, 
and the 3B20D in the AM. Associated with each control processor is 
an operating system running on the bare machine and a number of 
virtual machines that run on the operating system and provide more 
specialized services. 
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Fig. 6—Software architecture. 


The operating system in each processor creates the environment for 
the concurrent execution of a number of processes by scheduling and 
synchronizing these processes, providing services in the form of prim- 
itives, and managing system resources. The operating system running 
in the SMs is called Operating System for Distributed Switching 
(OSDS) and is specially designed for switching applications in a 
distributed architecture. In the AM there is a general real-time 
operating system developed for the 3B20D computer, called the UNIX™ 
Real-Time Reliable (RTR) operating system, as well as OSDS, running 
on RTR in the form of several processes and providing for other 
“inner” processes an environment similar to that found in OSDS-SM. 
The OSDS executing in the AM is identified as OSDS-AM. A special 
interprocess message mechanism is provided in all OSDS environments, 
allowing processes in different processors to communicate directly. 
Therefore, the OSDS operating system spans all processors, creating 
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a distributed environment in which processes executing in different 
processors can cooperate toward the implementation of particular tasks. 

The virtual machine just above the operating system in the hierarchy 
is the Data Base Manager (DBM). The 5ESS switch does not have a 
single uniform database but a collection of separate databases with 
their corresponding DBMs. Some of these databases are distributed 
among several or all processors. 

The next higher virtual machine is the abstract switching machine. 
It provides a number of logical entities such as terminal, port, 
connector, and path and a set of operations for manipulating these 
entities. The software running above this layer can thus provide the 
switching functions without having to know the detailed implementation 
of the switching hardware. 

Further beyond these virtual machines, the remaining software can 
be regarded as the application software. It provides major system 
functions such as call processing, maintenance, and administration by 
employing the services of the lower virtual machines. The application 
software is structured as processes running on different processors. 

The call-processing application software for the 5ESS switch also 
incorporates a highly modular and structured design that is functionally 
partitioned into several subsystems, such as a feature control subsystem 
and a peripheral control subsystem. Feature control is responsible for 
sequencing call-processing actions at a hardware-independent level by 
sending commands to the peripheral control that manages and controls 
the switching periphery. This partitioning is applied to the software 
in both the AP and the MPs. When feature software is separated, new 
features as well as hardware enhancements can be introduced in a 
relatively straightforward manner. 

Additional software is provided for administrative features in the 
areas of traffic measurements, plant and service measurements, and 
charge recording. Trunk and line maintenance, maintenance personnel 
interface, initialization, fault detection, and overload control are pro- 
vided by various maintenance software subsystems. All software is 
supported by the operating system, which manages the computing 
resources for the 5ESS switch. 


Ill. OPERATIONS AND MAINTENANCE 


All of the operations and maintenance functions can be optionally 
provided either locally or remotely on a single-office basis, or remotely 
on a centralized basis serving many offices. The major functions are 
discussed below. 


3.1 Switch maintenance 


The MCC is the primary communication medium between mainte- 
nance personnel and the 5ESS system. It displays system status and 
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alarm information, and it provides system control functions, message 
input and output, and telephone communication with work areas both 
inside and outside the exchange. Together with the exchange alarms, 
the MCC offers a complete set of switch and terminal maintenance 
features. The MCC provides trunk and line maintenance features. 
Separate Trunk Line Work Stations (TLWSs) are also available for 
this purpose. 


3.2 Line and trunk maintenance 


All trunk and line maintenance features can be invoked from either 
the MCC or an optional TLWS. The optional TLWS is physically 
identical to the MCC but is restricted to trunk and line maintenance 
functions. The TLWS performs the following functions: testing sub- 
scriber lines, operational testing of trunks, transmission testing of 
trunks, removing trunks and lines from service, and restoring trunks 
and lines to service. 


3.3 Database administration 


The 5ESS switch stores translation data in a relational database. 
The 5ESS Data Base Management System provides database access 
for maintenance and operations personnel and protects against the 
introduction of many types of database errors. Data-change and data- 
retrieval requests made from the MCC or an optional recent-change- 
and-verify work station add, change, delete, or verify individual records 
in the database. Automated office-record production is also provided. 


3.4 Billing 


The 5ESS switch provides two billing methods: detailed billing and 
Periodic Pulse Metering (PPM). One billing method may be chosen 
for all calls, or both methods may be used in the same 5ESS system 
for different types of calls (e.g., PPM for local calls and detailed billing 
for long-distance calls). Billing data may be recorded locally or sent 
via data links to a centralized recording system. 

Detailed billing records are in the form of a standard single entry 
for each call. PPM pulses are recorded in software registers (a software 
register can be provided for each subscriber) and, in addition, can be 
transmitted to the subscriber over the subscriber line. 


3.5 Measurements 


Traffic measurements give data for the performance supervision of 
the exchange, for traffic engineering of the network and service circuits, 
and for long-range exchange planning. To realize this objective, the 
5ESS switch continuously measures exchange traffic and provides 
appropriate reports. These reports can be produced either on a stand- 
alone basis or through an operations system. 
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Other measurements provided by the 5ESS switch fall into the 
following categories: 

1. Call attempts—These measurements represent the demand for 
service at the exchange and include traffic distribution (i.e., originating 
calls, incoming calls, etc.) and the traffic mix (i.e., coin, PBX, and 
feature calls). 

2. Processed calls—These measurements represent the service sup- 
plied and include outpulsed and answered calls. 

3. Switching system—The measurements in this category are related 
to the switching system components and include performance measures 
of the AM, CM, SMs, peripheral units, and service circuits. 

_ 4, External periphery—These measurements are related to the 
performance of other exchanges and trunk groups. 

5. Ineffective call attempts—The main objective of these measure- 
ments is to determine the cause of ineffective call attempts so that 
appropriate corrective actions can be taken. 


3.6 Centralized operations and maintenance 


Centralized maintenance arrangements may be provided either by 
means of remote work stations or Operations Support Systems (OSSs) 
that increase the effectiveness of operations and maintenance personnel. 
Color terminals with pictorial equipment and status displays provide 
enhanced maintainability. Additionally, menus and standard forms 
with a cursor-control capability enhance telephone company operations. 

Although the 5ESS switch provides the human interfaces necessary 
for performing all operations and maintenance tasks, it is also com- 
patible with several OSSs to increase the efficiency of the operations 
and maintenance personnel. 

1. Switching Control Center System (SCCS)—SCCS provides facil- 
ities needed for efficient centralized maintenance of stored program 
control electronic switching systems manufactured by AT&T Tech- 
nologies and others. It includes a minicomputer that performs real- 
time and batch analysis of the 5ESS switch output messages and 
alerts maintenance personnel if the data show any abnormalities. 

2. Remote Memory Administration System (RMAS)—RMAS is a 
multimicroprocessor system that increases the efficiency of centralized 
database administration for most types of electronic switching systems. 
It significantly reduces the time required to enter recent changes and 
to retrieve data, automates the production of office records, and 
provides reports that assist in managing both database and the 
personnel performing this work. 

3. Engineering and Administrative Data Acquisition System (EKA- 
DAS)—EADAS is a minicomputer-based real-time traffic data collection 
_ and reporting system. It has the capacity to gather data from up to 48 
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exchanges. The traffic reports generated for any particular exchange 
can be routed, via a data link, to a terminal in the exchange, to a 
central location, or to the printer at the EADAS site. The reports are 
similar to those provided by the stand-alone 5ESS switch. A program- 
ming capability is also available to develop other types of reports, if 
desired. EADAS also writes the collected traffic data on magnetic tape 
for further processing. This provision can be used, for example, to 
generate weekly, monthly, or busy-season reports for engineering and 
administrative purposes. 

4, Centralized Automatic Reporting on Trunks (CAROT)—CAROT 
is a minicomputer-based system that controls transmission and oper- 
ational trunk tests for all exchanges in a particular area that are 
equipped with comparable remote office test lines and responders. 
Routine tests are automatically scheduled, performed, and analyzed; 
the results are automatically forwarded to the appropriate maintenance 
personnel. 

Efforts are now being directed at providing interfaces to the OSSs 
and data collection systems used by foreign and independent admin- 
istrations. An early application interfaces with a PDU-10 for United 
Telephone. 


IV. ARCHITECTURAL EVOLUTION PLANS 


The modular and distributed nature of the 5ESS system, in both 
hardware and software design, allows it to continuously evolve as new 
technology and new market opportunities arise. Several major areas 
of architectural evolution are planned: 

1. Business and residence custom services—The 5ESS system will 
provide a set of features with a number of options to be selected by 
the customer. This modular feature customization gives the telephone 
administration greater tariffing options and assignment capabilities to 
meet the individual differences in customer needs. This mechanism, 
built entirely in software, can be applied to all customer lines, both 
individual lines and Centrex lines. It also creates new services by 
allowing many features to work together that never could before. For 
example, one service would allow for bridging from a call-waiting 
arrangement, where the called party talks to two calling parties 
alternately, to a three-way call in which all the parties can communicate 
simultaneously. 

2. Integrated services digital network services and capabilities—The 
international community, through CCITT, is developing standards for 
the integrated services digital network. The 5ESS system will provide 
end-to-end digital services via simultaneous circuit-switched voice or 
data, and packet-switched data, with out-of-band digital signaling. 
These capabilities will be provided over basic Digital Subscriber Lines 
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(DSLs), multiplexed DSLs over carrier systems, and primary rate 
DSLs over T-carrier. 

3. High-capacity architecture—The 5ESS system presently is capable 
of handling approximately 200,000 peak calls per busy hour, assuming 
a varied mix of call types and a normal level of maintenance and 
administrative activities. This will support a typical 50,000-line office, 
with a maximum of 48 SMs, both local and remote. In the near future 
the capacity will be expanded to over 300,000 peak calls. Overall, a 
100,000-line system will be accommodated. Beyond this large capacity, 
the 5ESS system could potentially grow to 500,000 or 1 million peak 
calls per hour with the continued modular addition of process- 
ing power. 

4, Larger remote units—The initial RSM for the 5ESS system is 
capable of handling 4000 lines. This architecture can be extended to 
larger line sizes for application in larger office replacements, or with 
trunking capability as a toll access and routing node. The ability to 
continuously evolve from a small remote to a large remote to a stand- 
alone office offers the telephone administration the flexibility to meet 
uncertain and fluctuating market demands with a minimum capital 
investment. 

5. Remote units over lightguide facilities—The 5ESS system cur- 
rently uses integrated digital T-carrier facilities between the host 
exchange and remote units. However, the fundamental design of the 
5ESS system uses fiber-optic lightguide facilities as the interconnection 
mechanism between the CM and the SMs. This mechanism will be 
extended so that remote modules using direct fiber-optic connections 
will be a reality. This will be especially important in metropolitan 
areas, where large demands are making lightguide facilities the economic 
choice. 

6. Integrated special services—A sizable portion of switching equip- 
ment and transmission facilities in metropolitan areas are dedicated 
to special services. Special services distinguish themselves from ordinary 
telephone service because they typically have more complex transmis- 
sion and/or signaling requirements, they generate higher traffic loads, 
and they have more volatile growth and turnover rates. Consequently, 
installation, provisioning, and testing functions are, in general, more 
involved, leading to higher operating expenses. The 5ESS system with 
its direct digital interfaces to interoffice T-carrier and to subscriber- 
side SLC 96 systems, together with a planned semipermanent connec- 
tion mechanism (nail-up) for full-time circuits, will allow it to eliminate 
and reduce many of the problems associated with special services. 


V. SUMMARY 


The 5ESS system incorporates sophisticated new technologies in its 
design. These technologies include GDXs, digital signal processors, 
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fiber optics, and distributed control elements. Its modular, distributed 
architecture creates a reliable and flexible system for continued evolution 
of new capabilities and services. The 5ESS system uses state-of-the- 
art techniques to provide a modern software architecture built upon 
layers of carefully structured virtual machines. The resulting software 
system is implemented using the C language high-level programming 
language and provides a high degree of modularity and extensibility 
appropriate for feature additions for years to come. 
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The operational software of the 5ESS™ switching system has been designed 
to meet specific objectives for capacity, functionality, and reliability. It has 
also been designed to accommodate changing technology, changing system 
applications, and an ever-increasing feature application set. Structured pro- 
gramming techniques, high-level languages, and modular design techniques 
have been used to obtain these objectives. Specifically, the operational software 
architecture is organized as a set of functional software components utilizing 
the advantages of a generalized operating system and database manager to 
achieve a high degree of hardware independence. A primary cause for hardware 
churning is the introduction of new peripheral units in support of new feature 
applications. The peripheral control software shields the majority of the 
operational software from these changes. Standardized and locally well-defined 
interfaces to the operations support systems provide information to the 
customer for the administration and maintenance of the switching system. 


]. INTRODUCTION 


The operational software of the 5ESS switching system has been 
designed to meet specific capacity, functionality, and reliability objec- 
tives. It has also been designed to accommodate changing technology, 
divergent system applications, and an ever-increasing feature application 
set. To meet these objectives the design stresses structured programming 
techniques, use of high-level languages, and modular design techniques.’ 

In this paper we describe the operational software architecture 
within the overall 5ESS system design. We show the organization of 
the software as functional components (see Fig. 1) and discuss the 


* Authors are employees of AT&T Bell Laboratories. 


Copyright © 1985 AT&T. Photo reproduction for noncommercial use is permitted 
without payment of royalty provided that each reproduction is done without alteration 
and that the Journal reference and copyright notice are included on the first page. The 
title and abstract, but no other portions, of this paper may be copied or distributed 
royalty free by computer-based and other information-service systems without further 
permission. Permission to reproduce or republish any other portion of this paper must 
be obtained from the Editor. 


1357 


o 


\\ 





— 
VG 


SWITCHING 
MODULE 













DIGITAL 
FACILITY 


i) 


REMOTE 
SWITCHING 
MODULE 











SWITCHING 
MODULE 


x= 
r=) 
nn 
4 


i 


100 MILES ¢ 
e 













SWITCHING 
MODULE 


COMMUNICATIONS 
MODULE 









5. 
| 


REMOTE 
SWITCHING 
MODULE 


ADMINISTRATIVE 
MODULE 


Fig. 1—Architecture of the 5ESS switching system. 


advantages of using a generalized operating system and database 
manager to achieve a high degree of hardware independence. 

We also discuss control of the peripheral hardware and administrative 
services such as measurements and billing. The call-processing scenario 
ties these design components together. Finally, we demonstrate how 
the remote switching capability extends the design. 


Il. SOFTWARE ARCHITECTURE 


The software system of the 5ESS switching system (see Fig. 2) 
comprises subsystem modules that communicate with each other using 
concisely defined message protocols and logically based primitives. The 
subsystems are designed to be loosely coupled, and almost all subsystems 
are largely independent of the system hardware and the internal data 
structures. 

An operating system isolates the application programs from the 
specific processors and allows portability of these programs across 
processors. The operating system is designed to present a single virtual 
machine environment to application programs operating in a distributed 
and decoupled multiprocessor environment. 

The data base management subsystem provides the interface between 
the other subsystems and the physical data. Using a relational database 
design, it shields the application programs from the actual implemen- 
tation of both dynamic and static data. 

Similarly, the peripheral control subsystem serves the hardware- 
independent subsystems by managing and controlling the switching 
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Fig. 2—Software architecture of the 5ESS system. 


periphery. The periphery includes the switching networks, service 
units, and line and trunk units. Lines and trunks terminate at the line 
and trunk units, respectively, and are referred to as terminals in this 
paper. The peripheral control subsystem performs all signaling, super- 
vision, alerting, digit reception, and outpulsing functions. A change in 
a peripheral unit usually requires program changes only in this 
subsystem and is not propagated into the application software. All the 
programs to control the switching periphery are resident in the 
Switching Module (SM)* except for programs that control the Time- 
Multiplexed Switch (TMS), which are resident in the Administrative 
Module (AM). 

The feature control subsystem is responsible for sequencing all 
logical call-processing actions associated with residential, business, 


* Acronyms and abbreviations used in the text are defined at the back of the Journal. 
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toll, and system features. This subsystem receives terminal inputs in 
the form of supervision changes or dialed digits, interprets this input 
based on the terminal’s current state, and, when needed, obtains more 
information from the Data Base Manager (DBM). It then requests 
that the peripheral control subsystem perform the required actions. 
Programs of the feature control subsystem that perform basic line and 
trunk call-processing functions are resident in the switching modules. 
Optional features or features invoked less frequently are implemented 
by program modules that can reside in either the administrative or 
switching module. Placement of these program modules is determined 
based on how frequently they are used and the resulting trade-offs of 
processor capacity and memory resources. This can be accomplished 
with minimal program modification. The software architecture and 
design philosophy permits the flexibility to best match feature usage 
with processor placement, thus assuring that the total system resource 
utilization can be balanced properly. 

The routing and terminal administration subsystem provides central 
routing and screening functions in support of the other subsystems. 
For example, the feature control subsystem passes a set of dialed digits 
to this subsystem, which in turn determines the destination of the 
call. The call destination is characterized by the switching module and 
terminal to which the call will be completed. In addition to the central 
switching resource allocation and routing function, the subsystem 
provides supporting functions, such as terminal status information, for 
other subsystems. Because of the global nature of these functions, this 
subsystem resides primarily in the administrative module. 

The administrative services subsystem provides message accounting 
or billing; traffic and plant measurement collection and outputting; 
network management functions; and interfaces to the external opera- 
tions support systems, such as the Remote Memory Administration 
System (RMAS) and the Engineering and Administrative Data Ac- 
quisition System (EADAS). The programs in this subsystem collect 
data from the other subsystems on a per-event basis, and perform 
analysis and storage for delivery at prescribed intervals or on demand 
to the external support system via data links. In addition, queries and 
commands from these external systems are distributed by this subsystem 
to the appropriate operational subsystem for action. The administrative 
services program modules are principally resident in the administrative 
module with data collection programs placed in the switching modules 
to retrieve per-event descriptions. 

The maintenance subsystems perform fault recovery and system 
integrity functions and are resident in the appropriate module. Various 
audit programs are automatically brought into play when inconsistencies 
or hardware failures are detected. They are also scheduled on demand 
when the integrity of dynamic data is suspect. 
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Ill. OPERATING SYSTEM 


The Operating System for Distributed Switching (OSDS)? provides 
the processing environment required by operational, switch mainte- 
nance, and system integrity software resident in the different modules. 
OSDS performs five major functions: 

1. Processor isolation 

2. Concurrency control 

3. Intra- and interprocessor message communication 

4, Resource scheduling 

5. Timing. 

The operating system is designed to support the decoupled network 
view of the 5ESS switching system design, i.e., it allows the view of 
the switching system as a collection of independent processors with 
well-defined interfaces via a concise message protocol. In essence, the 
design can be viewed as a collection of independent switches admin- 
istered as one switching center. 

A common machine-independent portion of OSDS includes the 
implementation of process management, interprocess communication, 
timing services, and scheduling. The machine-dependent portion, a 
small part of the total operating system, interfaces with the hardware 
processor and the host operating system supplied with the administra- 
tive module processor. It includes interrupt handling, process dispatch- 
ing, basic memory management, interprocessor communication, and 
communication to the host operating system. 


3.1 Processor isolation 


The 5ESS switching system architecture is designed to have a long 
lifetime. As hardware technology evolves, it is desirable to upgrade a 
processor without affecting the design of the software to any measurable 
extent. OSDS is designed to provide a virtual machine environment 
whose interface to the operational software remains constant through 
processor evolution. The fact that the operating system hides the 
unique hardware configuration from the operational software assures 
the expeditious porting of such software and preserves the investment 
in software development. 


3.2 Concurrency control 


The operating system concept of a process was adopted to facilitate 
understanding of the large number of concurrent activities in the 
switching environment. Concurrency is a significant design consider- 
ation owing to the large number of active terminals or phone calls at 
the same time. The software structuring concept of a process enables 
an operational software designer to program each activity (e.g., providing 
dial tone or ringing a line) as a sequence of separate tasks in a process. 
Multiple instances of this process are then executed concurrently by 
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the operating system to provide the concurrency control necessary to 
simultaneously process a multitude of telephone calls. This approach 
reduces the complexity of the design, since the designer can focus 
most of his/her attention on the external behavior of the process and 
its interaction with the environment and not on the interactions of 
the processes with each other. The process concept also structures the 
software system as highly modular parts with limited and well-defined 
interfaces. Communication with other processes takes place via messages 
routed to the appropriate destination by the operating system. 


3.2.1 Structure of processes 


Within the scope of OSDS there are two process types: terminal 
process and system process. 


3.2.1.1 Terminal process. All the activities on an active terminal are 
controlled by at least one terminal process. A typical call has two 
terminals and two associated terminal processes controlling the origi- 
nating and terminating party. Each terminal process thus keeps a 
partial view of the call and responds only to well-defined inputs from 
its associated terminal or other processes. 

This terminal-oriented process approach reduces programming com- 
plexity because it allows the designer to concentrate on the events 
specific to an individual terminal, the action necessary for processing 
such events, and interaction with other processes. The terminal- 
oriented process approach is more natural because the designer can 
assume the terminal user’s point of view in designing a program to 
control the terminal. Feature enhancements can be implemented by a 
simple addition to feature control programs that are callable by 
terminal processes. This approach is also well matched to the distributed 
aspects of the call-processing job when a call originates in one module 
and terminates in another. Having one terminal process in each module 
permits a natural division of the processing between the two modules. 

Terminal processes are created and terminated on demand. Typically, 
these processes are created on origination and terminated at disconnect 
time. They are activated by the arrival of an external stimulus or 
input signal from the terminal or another process. After processing a 
signal, the terminal process takes a “real-time” break by releasing 
control to the operating system and waits for further input. There are 
separate control programs for different terminal types. For example, 
there are residential, coin, and multiparty terminal control programs. 
These programs determine the control sequence required for their 
particular terminal type. The majority of the processes in the system 
are terminal processes, sharing the use of the various control programs. 


3.2.1.2 System process. There are also some long-standing processes 
that function as servers within or outside of call processing. Examples 
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are dispenser processes, which distribute inputs to terminal processes; 
the routing and terminal allocation process, which assists in routing 
the call; the data base manager process, from which a terminal process 
can request data characterizing the physical terminal; and the system 
audit process, which performs the routine software sanity checks. 
These are called system processes since they provide services on a 
systemwide basis. They are typically created at system initialization 
and remain active indefinitely. Each system process carries out a 
specific function and handles requests from more than one terminal 
process. In general, a system process is a self-contained program and 
does not share programs with other processes. 


3.3 Message communication 


Message communication is the major communication mechanism 
between processes. Basically, a sender prepares a message in a message 
buffer and then invokes the operating system using a message com- 
munication primitive to transmit the message. The operating system 
determines the destination of the message. If the message is addressed 
to a process within the same processor, the operating system copies 
the message to the receiving buffer and schedules the receiving process. 
In case the message destination is external to the processor, a 
communication control program is invoked to transmit the message 
through a physical link. In a similar fashion, incoming messages are 
received by the communication control program and transferred for 
proper routing to OSDS. 


3.4 Resource scheduling 


Resource scheduling involves the central allocation and assignment 
of memory resources and processor time. When the operating system 
schedules a process, it assures that sufficient memory resources are 
available for that process to run. The operating system is designed in 
a self-regulating manner intended to meet system performance at the 
rated call-carrying capacity and to satisfy stringent response times to 
the craft personnel. It also responds to external stimuli from an 
overload control program to take corrective actions, if necessary, and 
preserve system throughput. 

The scheduling is done at different priority levels with each type of 
process assigned a specific priority. Overload control reacts to momen- 
tary bursts of traffic input or resource shortages and provides input to 
the scheduling algorithms. A sanity timer protects the system against 
any process taking control of the processor for longer than a maximum 
allowable time. A cyclic timer interrupt assures that high-priority jobs 
with stringent timing requirements are executed with the appropriate 
frequencies. 
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3.5 Timing 


The operating system administers two classes of timing services. 
The first, essentially a time of day clock, is used for billing purposes 
and for time-stamping events. Second, each OSDS processor maintains 
a clock used in conjunction with an ordered queue of timing requests 
that allows each process to request control from OSDS at specified 
time intervals. 


IV. DATA BASE MANAGEMENT SYSTEM 


The Data Base Management System (DBMS)? promotes the overall 
5ESS system objectives of modularity, portability, and system evolution 
by providing a single access to the data which is totally at the logical 
level as viewed by the users of the data. The DBMS supports the 
distributed architecture of the system by providing distributed data 
and distributed management of the data. Most data required by a 
particular processor are contained within that processor. The DBMS 
makes the location of all data transparent so that other programs need 
not be concerned about on which processor the data actually reside. 
The DBMS is a specialized distributed system based on the relational 
data model and is subject to stringent performance and reliability 
requirements. The balance between real-time constraints and reliability 
requirements is largely achieved by a concurrency mechanism that 
provides the necessary real-time access while maintaining a consistent 
view of the data. 

The Data Base Management System provides: 

. Data definition 

. Data access 

. Concurrency control 

. Memory partitioning and write protection 
. Data backup and recovery 

. Data administration. 


ow»r wn 


4.1 Data definition 


Any database management system should provide a measure of data 
independence. In the 5ESS switching system, data are defined off-line 
and changes can be introduced by redefining database relations and 
automatically recompiling user programs. The goal is to introduce 
database changes with a minimum number of client program changes. 
Because the schema remains stable during a given software release, it 
is not necessary to define the database on line. A data definition 
language accepts user definitions of the relations and their domains 
and generates user header files, data dictionaries, and documentation. 
Figure 3 shows the data definition process and the major software 
components in a switching module. The administrative module contains 
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Fig. 3—Overall DBM architecture. 


similar components. The user header files contain the C-structure 
layout (or template) of the relations and are used to compile the client 
programs. The data dictionaries describe all the relations, attributes, 
and domains in the database. They are used internally by the DBMS 
software. 


4.2 Data access 


The DBMS provides two levels of interface in accessing the database. 
The two levels of interface achieve different degrees of data indepen- 
dence for users with different performance and data usage requirements. 
The basic interface is the tuple-level access, which is employed by 
real-time critical users, e.g., call-processing programs. The user at this 
level can retrieve tuples of the base relations. The base relations are 
designed from an operational point of view and are used by all internal 
subsystems. The base relations represent the actual physical data 
stored in the database. A higher level of interface, called the view- 
level access, is designed to provide a higher degree of data independence 
for users with less stringent real-time requirements. The view-level 
access operates on view relations, which are virtual relations formed 
at execution time by combining information from one or more base 
relations. The view-level access provides an interface to administrative 
operating telephone company personnel in a 5ESS switching system 
and also to Operations Support Systems through external data links. 
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Fig. 4—DBM interfaces. 


Since the view-level access is used to interface with the external users, 
it is only available in the administrative module. Figure 4 depicts the 
database management interfaces in the 5ESS switch. All of the 
resident application programs access data through the DBMS on the 
processor on which they are executing via a set of interface primitives. 
These primitives are function calls, as opposed to messages, which are 
the communication mechanism between processes. For accessing the 
data on a remote processor, the DBMS automatically generates all the 
necessary interprocessor queries (in terms of messages). 

The database is isolated from application programs. A function call 
causes some data to be copied from the database to a user buffer 
instead of providing a physical pointer to the database. This is done 
to ensure integrity of the data in the database. To fulfill the real-time 
requirement of call processing, the capabilities of the interface primitives 
are somewhat restricted. Only single tuples within base relations can 
be accessed. 
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4.2.1 Data access primitives 


The DBM provides a basic set of primitives that serves all users. 
The set of primitives is “complete” so that the user can access any 
part of the database, but it is “basic” enough so that the DBMS does 
not have to perform any part of the application for the user. The 
tuple-level access provides control and protection functions in addition 
to data access. It manages transactions, controls concurrent access, 
and handles data distribution. 


4.3 Concurrency control 


Concurrency control in the DBMS is a mechanism that allows 
multiple users to access the data and protects them from getting 
inconsistent data due to concurrent updates. The policy on concurrency 
control has a great influence on the design of the concurrency 
mechanism. It determines the efficiency of shared data usage or, in 
other words, the degree of concurrent access. 

Call processing is primarily a reader of the relatively permanent 
data and it contributes a large portion of the data access activity. 
Since call processing requires rapid real-time response, its access to 
the data has priority. Most changes to the database are not real-time 
critical and the frequency of such activities is rather low in comparison 
to call processing. Concurrency control is designed to provide ef- 
ficient access to read-only users with potentially delayed access to 
update users. 

The concept employed to control concurrent changes is based on 
data duplication. All updates are performed on a copy of the real data. 
During the update period, all readers of the database can still access 
the original version of the data. When the update is completed, the 
updated copy will become the real data for future users. The old copy 
will be discarded when all current read transactions on this relation 
are completed. 

This mechanism allows only one writer to the database in the 
system to update the same relation. This, however, does not restrict 
the number of readers who have read-only access to the relation. 
Furthermore, it does not restrict the number of writers who are 
operating on the disjoint parts of the database. This situation fits 
quite well in the 5ESS switching system’s environment, where there 
are many readers and relatively few, infrequent writers. Simultaneous 
writers of the same data page are queued internally to the DBMS, 
so virtual concurrent update operation is still seen by the user in 
this case. 

Since the concurrency control scheme is based on duplication of 
data, it is desirable to organize the storage structure in such a way 
that the amount of duplication is minimized. A tree-like storage 
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structure is most suitable for this kind of application. The amount of 
data duplication required to perform an update in a relation consists 
of all the blocks along the path from the root node to a leaf node. All 
relations are in a tree-like structure, regardless of what kind of access 
method is employed. 

When an update transaction terminates, the old data are replaced 
by the new data by changing the pointers to the control data structures. 
If the update process terminates abnormally (e.g., owing to software 
asserts or hardware reset) before the commitment of update, the 
current version of the data remains intact. The memory for new data 
that are never committed will be reclaimed immediately if possible, or 
will be subjected to garbage collection through data audits. 


4.4 Memory partitioning and write protection 


Write protection is a mechanism to protect the database against 
“wild” writes by any process. If an area of the memory is write 
protected, a process writing into this area must first turn off the write- 
protection mechanism. Otherwise, an interrupt will be generated and 
appropriate action will be taken on this process. Most unintentional 
writes to the database can be caught by this mechanism. Providing 
write protection for the whole database would create unacceptable 
real-time penalties for the telephone switching operations. To achieve 
a balance between real-time response and reliability, the memory is 
partitioned into a write-protected area and a non-write-protected area. 

Relatively permanent data are stored in write-protected memory. 
Examples of write-protected data are the data dictionaries that store 
the schema of the relational database, and information specific to the 
individual office: hardware configuration, telephone line and trunk 
data, digit dialing analysis data, and routing data. Another class of 
data that is more dynamic in nature is stored in the non-write- 
protected memory. This class of data is used to define system dynamics 
such as the state of a phone call, the status of hardware equipment, 
work queues, etc. Dynamic data do not rely on disk backup for data 
recovery. Instead, data are recovered through a system of audits that 
either recover the data from the office-dependent data or from program 
initialization. 


4.5 Data backup and recovery 


For access efficiency, most of the data are stored in main memory. 
Since a power failure can destroy the entire main memory content, 
secondary disk storage units are utilized to back up all main memory. 
The disk backup is also used to restore main memory data whose 
integrity is suspect. An elaborate set of audit programs are used to 
constantly check the data integrity. The DBMS continually keeps the 
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disk data logically equivalent to the main memory to prevent loss of 
the latest data updates in the event of data recovery from disk. 


4.6 Data administration 


A data administration capability is provided by the 5ESS switch to 
enable the operating telephone company and the telephone subscriber 
to dynamically change the feature capabilities available to them. The 
programs used to provide the data administration capability are called 
Recent Change and Verify (RC/V) programs. The primary design 
objective is to provide a user-friendly, interactive interface with max- 
imum flexibility. A comprehensive set of error checks are made on all 
data entered, with particular emphasis on identifying the exact cause 
of the error and the specific steps required to correct the error. All 
error checks must pass successfully before the data in the 5ESS switch 
will be updated, thereby ensuring a high degree of data integrity. 

The RC/V program provides the ability to add, delete, update, or 
verify the database using 

1. A menu select/mask interface 

2. A text interface 

3. An operations support system interface (see Fig. 4). 

The menu select/mask interface is supported from multiple recent 
change terminals (CRTs), which can be utilized concurrently, while 
the other two interfaces are associated with unique terminals. All 
interfaces are provided over dedicated facilities. The user specifies one 
of two levels of menu select. The first level of RC/V menu select 
allows the user to specify which form (user view) is being used. These 
can be verify only, or a combination verify and recent change forms. 
The second level requires the user to select the type of operation to 
be performed (i.e., recent change—new, out, change, or verify) on that 
form. After the user specifies both the form and the operation, the 
form is displayed and the RC/V data interpretation and processing 
subroutines are invoked. 

The menu-select program also determines if a particular user terminal 
is allowed to perform the requested RC/V operation. Following is a 
list of valid terminal types and a description of the allowed RC/V 
operations: 


Description Operations Allowed 
Local-RC/V All 
Remote-—maintenance All 
Repair service bureau Verify only 
Network administration Verify all data 


Network, administrative data 
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Line administration Verify all data 
Line group data 


A user may obtain a permanent copy of all recent change activities 
by specifying an auxiliary printer. In this case the menu program will 
generate a print file that consists of a serialized record of the RC/V 
operations that occurred in a terminal session. Each time the database 
is recent changed or verified, a copy of the completed form is written, 
along with the time and view transaction identifier and an indication 
of the time the transaction was actually committed in the database. 

As an additional option, a scratch print file contains a copy of the 
input forms used, along with any error messages obtained. The file is 
written whenever the user specifies. This allows the user to obtain a 
paper copy of his or her input and allows errors in input to be resolved 
off-line. 

The RC/V program performs range and syntax checks on each 
attribute put into the system. In addition, data consistency checks are 
made by comparing all attributes of a particular form when the user 
indicates that input for a particular form is complete. Finally, before 
committing any database changes, a data integrity check is made so 
that the data input on a particular form does not conflict with any 
data already in the database. 


V. PERIPHERAL CONTROL 


In the 5ESS switch software architecture, it is the function of the 
peripheral control subsystem to isolate application programs from the 
details of switching machine hardware. It provides the sequencing and 
control for operations on the switching network, service units, and 
line and trunk units that comprise the switching periphery. As a 
result, other subsystems can view the switching hardware as a collection 
of logical resources, unencumbered by the details of the particular 
hardware implementation. 

The abstract resources that peripheral control provides are logical 
ports, paths, bridges, and connectors. A logical port is an abstraction 
of the customer terminal’s attachment to the system. Bridges and 
connectors represent the various types of conferencing capabilities. 
Paths represent the interconnections of logical ports, bridges, and 
connectors. 

The peripheral control subsystem is divided into four parts: 

1. Port control—implements the concept of logical ports and provides 
a set of primitives to operate on them. 

2. Switching resource allocator—controls allocation of various 
switching resources, such as time slots and service units. 

3. Network control—coordinates path operations in the digital and 
metallic access networks. 
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4, Peripheral I/O—provides low-level sequencing and control of the 
switching periphery, including the handling of time-critical I/O. 
Each of the four major components of the peripheral control subsystem 
is described in more detail in the following sections. 


5.1 Port control 


Port control software resides only in the switching module and 
provides a set of primitives to operate on logical ports. Through these 
primitives, the application software can deal with line and trunk 
terminations as conceptual entities, unconcerned with the detailed 
sequence of operations required to control the hardware. For example, 
a primitive is provided to “activate” a line termination port by 
establishing a path through the line concentrator, performing false 
cross and ground tests, and initializing the associated software data 
structures. Another primitive is available to apply dial tone (or other 
appropriate signal) to a logical port. This approach provides an abstract 
view of the switching periphery that leads to higher productivity in 
the development of new features. It also allows for the periodic 
introduction of improved, lower-cost hardware units without modifi- 
cation of the application software. 


5.2 Switching resource allocator 


The switching resource allocator provides a set of primitives to 
allocate and deallocate switching resources. These resources can be 
divided into two categories: (1) paths in the switching network, and 
(2) service units. Path resources include line concentrator paths, 
peripheral-side Time-Slot Interchanger (TSI) time slots, and metallic 
access paths.* 

Service units include the High-Level Service Circuit (HLSC), the 
Local Digital Service Units (LDSUs), and conference circuits in the 
global digital service units. The HLSC is a circuit in the line unit that 
is used to verify concentrator paths, provide cadenced ringing, and 
perform the needed operations for coin phones. The LDSUs are used 
to generate and decode digital tones used in call processing. Conference 
circuits are used for bridging and three-way calling. 

In addition to allocation and deallocation of switching resources, 
functions are provided to queue for, or preempt, resources. Queueing 
would be used, for example, when circuit diagnostics must be run on 
a hardware unit that is currently in service. Preemption allows a client 
to gain control of a resource regardless of its current status. Preemption 
is not a routine activity. It is used primarily in support of high-priority 
maintenance actions. 


* Metallic access paths are used by the terminal maintenance subsystem for testing 
lines and trunks. 
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5.3 Network control 


Network control coordinates the actions required to set up and 
release call paths. It presents a high-level abstraction for feature 
control to operate on the switching network. It is through the network 
control software, which resides both in the switching and administrative 
modules, that the abstractions of paths, bridges, and connectors are 
realized. 

Central network control software coordinates path operations, such 
as path setup, path teardown, and network reconfiguration, that 
involve the Time-Multiplexed Switch (TMS) or multiple modules. 
Through interactions with local network control, it determines what 
new paths and conference circuits are needed, reserves the appropriate 
resources, and sends orders to the TMS to connect the paths. 

Local network control software is responsible for making connections 
between the originating or terminating port and the module network 
control and timing link. It also plays an essential role in coordinating 
the sequence of path operations required for establishing and releasing 
an intermodule path, and in inserting or dropping bridges and connec- 
tors. The coordination required is a function of the characteristics of 
the network and is transparent to application software such as feature 
control. 


5.4 Peripheral input/output 


Peripheral input/output software is responsible for the sequencing 
and control of the switching periphery. Of all the peripheral control 
components, it operates at the lowest level, closest to the hardware. It 
performs both time-critical I/O jobs (10-ms interrupt level) and base- 
level I/O jobs whose time constraints are not as stringent. Peripheral 
I/O software typically performs these jobs at the request of port 
control or network control programs and provides isolation from the 
details of the peripheral hardware. 

Interrupt-level (foreground) processing is responsible for handling 
those tasks that require an immediate response. Examples of jobs that 
fall into this category are 

1. Service requests from the periphery 

2. Line origination scanning 

3. Dial pulse and multifrequency outpulsing. 

Base-level (background) processing has less stringent timing con- 
straints. Background processing is started on a 50-ms cycle or on the 
reception of a report from foreground. It provides such services as 

1. Dispatching digit reports to port control 

2. Sending origination reports to origination-handling software 

3. Implementing the overall scheduling strategy for I/O jobs. 

The foreground and background peripheral I/O functions provide a 
fundamental set of services for controlling the peripheral hardware 
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and responding to external stimuli. These programs interact with the 
other components of peripheral control to provide the application 
software with an easy to use, abstract interface to the switching 


periphery. 
Vi. CALL-PROCESSING SOFTWARE 


Call processing‘ is principally the responsibility of three subsystems: 
Feature Control (FC), Routing and Terminal Administration (RTA), 
and Peripheral Control (PC). The roles and interactions of these three 
subsystems can be better appreciated by considering the flow of a 
simple line-to-line call. For this purpose let us assume that customer 
A originates a call to customer B (see Fig. 5). When customer A 
originates a call, the off-hook is detected by the peripheral control 
foreground program. Peripheral control, in turn, calls the RTA pro- 
grams, which create a feature control terminal process to control the 
call. Checks are made to determine the identity of the line, the type 
of service offered (individual, two-party, coin, etc.), the type of features 
offered, and the type of signaling used. A path through the concentrator 
is set up, a power cross test is run, a digit receiver is attached, and 
dial tone is returned to the customer. When the first digit is received, 
dial tone is removed. For the first digit and for each of those that 
follow, messages are sent to the terminal process, and the digits are 
subsequently analyzed. If there is no permanent signal, partial dial, or 
disconnect, the call continues as normal. 

At this point a request to terminate to the selected party is sent to 
the administrative module using a route request message. Here the 
RTA software determines the terminal associated with the called 
number (customer B). A path is then allocated between the originating 
and terminating terminals, the required time slots are identified, and 
the TMS is ordered to provide the connection. A termination message 
is sent to the interface module of customer B, and RTA then creates 
a terminating terminal process after checking for special features on 
the terminating line. A path through the concentrator is established, 
a power cross test is run, the appropriate ringing signal is started, and 
audible ringing is connected through the terminating Time-Slot Inter- 
change (TSI), the TMS, and the originating TSI, back to the originat- 
ing party. 

When customer B answers, an off-hook is detected by the PC 
foreground program, which informs the terminating terminal process 
after checking for special features on the terminating line. Ringing is 
removed by the hardware when customer B goes off-hook; subsequently, 
the audible ringing is removed and the terminating line is cut through. 
The parties are now talking. 

Assume that the terminating party, customer B, hangs up or 
disconnects. In this instance, the peripheral control program sees the 
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on-hook and reports it to the terminating terminal process, which in 
turn sends a clear-back message to the originating terminal process. 
The originating process then begins disconnect timing. At this point, 
if either the originating party hangs up or the disconnect timing 
expires, the originating terminal process releases the call’s time slot 
by sending a path release message to the administrative module. The 
terminating terminal process is also notified to release the path. It 
responds by idling the appropriate time slot, sending a message to the 
administrative module, sending a release guard message to the origi- 
nating terminal process, idling customer B’s port, and terminating 
itself. When the originating terminal process receives the release guard 
message, it idles customer A’s port and terminates itself. Meanwhile, 
after the administrative processor receives the path release message 
from each process, it instructs the TMS to idle the path, thereby 
completing termination of the call. 

There are many variations of this basic sequence, but the above 
description is the typical flow for a simple line-to-line call. In the case 
of three-terminal calls, such as call waiting or three-way conferencing, 
there is still only one terminal process associated with each terminal, 
and one of these terminal processes is responsible for providing the 
overall coordination required during the call. Even with multiterminal 
calls that are made up of two or more three-terminal calls, only one 
terminal process is required for each terminal and overall coordination 
responsibilities rest with one of the terminal processes. Only with 
interactive multiterminal calls is there a need for a separate call- 
coordinating process. 


Vil. ADMINISTRATIVE SERVICES 


Administrative services’? encompass collecting data, processing or 
formatting data, and outputting data to Operations Support Systems 
or local crafts people in the office. These wide-ranging data operations 
include billing, measurements, network management, and service eval- 
uation. Much of this administrative services software is based on the 
processing of events—call events and system events. Call events are 
associated with an individual call. Examples are answer or disconnect 
time, called number or origination data. System events, on the other 
hand, are not associated with an individual subscriber, but instead 
consist of such things as traffic or maintenance usage data or processor 
utilization data. Events are stored on a per-switching-module basis, 
with each module processor having a call-event buffer and a system- 
event buffer. 

It is the task of the call-processing and maintenance programs to 
recognize and report events to the administrative services subsystem 
using primitives that increment counters and associate data on a per- 
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Fig. 6—Structure of administrative services software. 


call basis. For example, the feature control subsystem reports the end 
of dialing, answer, and disconnect. The peripheral control subsystem 
recognizes that a circuit has been seized or a dial tone applied. The 
terminal maintenance subsystem recognizes line or trunk troubles, or 
per-call failures. In all instances, however, the event data collection 
and processing have been separated as much as possible from the call- 
processing and maintenance programs, and the data from a single 
event may be used for several administrative purposes. Only the event 
data needed are collected, and as new data are required, new admin- 
istrative primitives are defined. 

All the temporary data associated with an individual call are stored 
in a call record. The data are reported to the Call Record Assembler 
(CRA), which correlates the data, stores them in the proper call record, 
and makes the information available to the administrative services 
software. The memory for this record is dynamically allocated as 
needed. 

The administrative services software is functionally organized as 
shown in Fig. 6. Per-call events are received by the CRA and system 
events are generally handled by the data base management subsystem. 
These data are then made available to the billing, measurements, 
network management, and service evaluation programs for appropriate 
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processing and formatting of output records. These programs, in turn, 
interface with the external data link communication package, which 
provides a path to the many external data links that interconnect the 
5ESS switch with the operations support systems. 


7.1 Billing 


The Automatic Message Accounting Teleprocessing/Tape System 
(AMATPS) provides stand-alone Local Automatic Message Accounting 
(LAMA) tape operation and/or teleprocessing of automatic message 
accounting data to a centralized Host Collector system (HOC). The 
5ESS switch supports many different billing configurations. Alterna- 
tively, the 5ESS switch can support Centralized Automatic Message 
Accounting (CAMA) operation with Traffic Service Position System 
(TSPS) or with toll offices such as the 4ESS™ switching system. 

These billing configurations involve either real-time operation or a 
store and forward arrangement. Real-time operation implies that 
billing information is moved out of the office as quickly as possible. 
CAMA operation satisfies this definition. The possible real-time con- 
figurations are illustrated in Fig. 7, where Automatic Number Identi- 
fication (ANI) information is output to TSPS or to a toll office for 
CAMA operation. 
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With the store and forward arrangement, billing data are stored in 
a single-entry format on a disk. These data can be forwarded on 
demand to a LAMA tape, as shown in Fig. 7. Alternatively, the data 
may be teleprocessed on a polled basis to a HOC. The interface to the 
HOC can be a 4.8-kb/s dial-up link or a 9.6-kb/s dedicated link. 


7.2 Measurements 


A second major portion of administrative services is the measurement 
package. These measurements fall into three different categories: plant, 
traffic, and service evaluation. Some of these measurements are peg 
counts, others are usage counts, still others are overflow counts. All of 
these counts are processed and subsequently provided to the craft 
either locally or remotely through operations support systems in a 
very human-oriented form. All craft reports are appropriately formatted 
with titles provided so that no templates are required to decipher 
the data. 

The measurement package provides data to EADAS, the No. 2 
Switching Control Center System (No. 2 SCCS),° and the Master 
Control Center (MCC). Twenty-four-hour plant measurement data are 
provided to the SCCS and the MCC; 30-minute traffic reports and 
Division of Revenue data are sent to EADAS, and a 15-minute traffic 
report is always sent to the MCC, while the 30-minute report is 
provided on demand. Optionally, this information is available on a 
local printer. 


7.3 Network management 


The 5ESS switch provides a very powerful network management 
package, essentially as robust as that available with the 4ESS toll 
switch. The package provides real-time surveillance data and imple- 
ments an assortment of network management controls. All of this is 
intended to optimize the call-handling capacity of the switch and to 
maintain external network sanity during periods of traffic overload or 
failure. 

The 5ESS switch interfaces used to support network management 
are shown in Fig. 8. They include interfaces with EADAS/Network 
Management (NM), the No. 2 SCCS, and a local terminal. The 
communication with EADAS/NM in the Network Management Center 
(NMC) takes place through the No. 1A EADAS, and the 5ESS switch 
interfaces with EADAS through a dedicated 2400-b/s X.25 synchronous 
link. EADAS/NM is provided with data that includes five-minute 
surveillance data and thirty-second discretes. The crafts people, in 
turn, can invoke a variety of trunk group controls, including skip, 
cancel-to, cancel-from, and reroute. The reroute control allows out-of- 
chain routing during failure or overflow. Also available are code 
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Fig. 8—Network management interfaces. 


controls and call gapping. All network management controls that have 
been invoked can be retired with a single command from any of three 
different locations: the network management center, the switching 
control center system, or from a local terminal in the office. 


7.4 Service evaluation 


Service evaluation is a feature used to determine the quality of 
service experienced by the telephone customer. The process is now 
fully automated with the advent of the No. 2 Service Evaluation 
System (SES). The 5ESS switch interface with the No. 2 SES consists 
of a dial-up 2400-b/s X.25 synchronous data link and from one to four 
monitoring links. The arrangement supports dial-line service evaluation, 
as well as Mechanized Evaluation of Call Completion Anomalies 
(MECCA). The latter involves monitoring outgoing calls that have 
long holding times without answer supervision. The process helps to 
detect fraud and to find trunks that are faulty from a billing standpoint. 
MECCA can be used for all line-to-trunk calls and up to four calls 
can be observed simultaneously. 


Vill. REMOTE SWITCHING 


The Remote Switching Module (RSM) is the first of a series of 
digital remote switching products realized within the basic architectures 
of 5ESS switching system hardware and software. It provides to 
customers at the remote site the same services as those served by the 
host, and it meets the same demanding reliability requirements. The 
RSM, which can be located up to 100 miles from its host, permits 
economic replacement of Community Dial Offices (CDOs) with up to 
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4000 lines and the establishment of new wire centers with a smaller 
size than previously economical. 


8.1 Remoting facilities 


The RSM is a standard switching module that uses essentially the 
same hardware and software as an existing Switching Module (SM). 
It is connected to an SM at the host office using 4 to 20 digital 
facilities (see Fig. 1). Two or four of the digital facilities carry 
permanently reserved control time slots over which the RSM processors 
communicate with the rest of the system. 


8.2 Operational software design for remote switching 


The operational software for the RSM supports two modes of 
operation. The normal linked mode occurs when there is proper 
functioning of the communication channels between the RSM and the 
Administrative Module (AM) through an SM at the host. During 
linked operation, the RSM provides all of the calling features of the 
host office. The stand-alone mode is entered when communications 
over the digital facilities is lost owing, for example, to a cable cut. In 
the stand-alone mode, it provides normal handling of intramodule 
calls, including most custom calling services, and special handling 
of emergency and operator calls that would otherwise be routed to 
the host. 

The operational software design for the RSM takes into account 
three factors introduced by remote switching operation: 

1. Intermodule calls involving the RSM require an extra stage of 
time-division switching beyond that used for local switching modules. 
This stage is provided by the time-slot interchange unit of the SM in 
the host. 

2. Intramodule calls must continue to be served during stand-alone 
operation. Thus the call-processing design must handle intramodule 
calls independently of the AM. 

3. Special treatment of emergency calls is required during the stand- 
alone mode. In addition, intermodule calls must be given an appropriate 
failure treatment. 


8.2.1 Call connections for remote switching 


A major portion of the RSM-specific operational software controls 
the path allocation and path setup mechanisms necessary to incor- 
porate the additional stage of switching into the call connection 
software. This software is completely within the peripheral control 
subsystem and, consequently, the application-level software, such as 
Feature Control (FC), is unaware of the changes required to interface 
with the expanded switching network. In all, five additional path types 
are supported (see Fig. 9). 
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Fig. 9—Remote switching module path configurations. 


For a call between local switching modules, path setup is accomplished 
through interaction with network control in the AM. In a case 
involving the RSM, the procedure is very similar (identical from the 
feature control point of view). The roles of the originating and 
terminating terminal processes and the path setup protocol remain 
essentially the same. There are, however, some differences, which are 
hidden within peripheral control. The connection through the TMS 
must be made to the RSM’s Host SM (HSM). This is different from 
the local SM case, where the TMS connection is always made to the 
originating or terminating module itself. Also, the setup of the origi- 
nating or terminating portion of the path involving an RSM is more 
complicated since two modules, the host SM and the RSM, are 
involved. The primitive, which is used to set up the originating or 
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terminating end of the path, determines if it is executing in an RSM 
and, if so, coordinates with software in the host SM to establish the 
required connections. This coordination function is placed within the 
existing call connection procedure so that this activity is transparent 
to the call-processing actions on the other end of the call. 


8.2.2 Distributed routing for remote switching 


The administrative module provides the call-routing function for 
ordinary calls, and routing data therefore reside in the AM. Stand- 
alone operation in the RSM requires a more distributed approach. In 
this case, the local routing algorithm in an RSM proceeds through 
data accesses and manipulations relating to resident destination ad- 
dresses. If the destination of the call is an RSM terminal, defined in 
the extracted routing data stored in the RSM, all routing is handled 
by the RSM. If the data stored in the RSM are insufficient to 
determine the termination address, control is forwarded from the RSM 
to the AM, which completes the routing process. 

The call connection and distributed routing techniques provide a 
full complement of services to lines served by the RSM. They also 
provide the basis for stand-alone call processing, a mode that may be 
assumed (a telephone company option) when communications with 
the host fail. 


8.2.3 Stand-alone mode 


In the stand-alone mode, the RSM continues to handle intra-RSM 
calls normally and provides for special treatment of other calls. Normal 
intermodule calls, originating at the RSM and terminating on another 
module (including outgoing calls), are automatically routed to either 
an announcement or a reorder tone (telephone company option) at 
the RSM. Emergency calls, originating on the RSM and normally 
handled as intermodule calls, may be routed to designated lines on the 
RSM during stand-alone operation. Up to ten directory numbers may 
be specified in the emergency category. Global hunt groups (hunt 
groups with appearances on the RSM and one or more other switching 
modules) are reconfigured to permit hunting over the local subset of 
the global group during stand-alone operation. 


IX. SUMMARY 


This paper has described the operational software structure used to 
provide the major call-processing and administrative function in the 
5ESS switching system. It demonstrates the functional decomposition 
of the software through use of a general operating system and DBM, 
as well as a high degree of hardware independence achieved by use of 
the operating system and the peripheral control subsystem. 


1382 TECHNICAL JOURNAL, JULY-AUGUST 1985 


X. ACKNOWLEDGMENTS 


The authors wish to acknowledge the efforts of those designers, too 
numerous to mention individually, who contributed to the successful 
operational software system design. 


REFERENCES 


1. D. L. Carney et al., “The 5ESS Switching System: Architectural Overview,” AT&T 
Tech. J., this issue. 

. W. H. Huen et al., “SESS Switching System Software: Operating System Structure,” 
AT&T Tech. J., to be published. 

. M. R. Locher, L. R. Pfau, and D. W. Tietz, “SESS Switching System Software: 
Database Management System,” AT&T Tech. J., to be published. 

. D. A. Anderson et al., “SESS Switching System Software: Call-Processing Software 
Structure,” AT&T Tech. J., to be published. 

. J. M. Erickson et al., “SESS Switching System Software: Billing and Administrative 
Services,” AT&T Tech. J., to be published. 

. J. J. Bodner, J. R. Diano, and K. A. VanderMeulen, “Traffic Service Position System 
No. 1B: Switching Control Center System Interface,” B.S.T.J., 62, No. 3, Part 3 
(March 1983), pp. 941-57. 


an an ., WO ND 


AUTHORS 


John P. Delatore, B.A. (Mathematics), 1963, College of Steubenville, Steu- 
benville, Ohio; M.A. (Mathematics), 1965, Bowling Green University, Bowling 
Green, Ohio; AT&T Bell Laboratories, 1965—. Mr. Delatore has worked on 
Traffic Service Position System (TSPS) program design and TSPS test 
evaluation. He worked at AT&T from 1973 to 1975 providing computer-aided 
service cost methodologies. In 1975 he became Supervisor of the TSPS Growth 
and Field Support Group, and in 1977 he became Supervisor of the TSPS 
Planning Group. In 1979 Mr. Delatore was appointed Head of the Credit Card 
Data Base Feature Programming Department. Beginning in 1982 he worked 
on the database, factory system test software, and operational software for the 
5ESS switch. In 1984 Mr. Delatore assumed his current position as Head of 
the Local Switching Systems Engineering Department. 


Rudolph J. Frank, B.S. (Electrical Engineering), 1966, Seattle University; 
M.S. and Ph.D. (Electrical Engineering), 1968 and 1971, respectively, Oregon 
State University; M.S. (Business Management), 1981, Stanford University; 
Pacific Northwest Bell, 1964-1966; AT&T Bell Laboratories, 1971—. At Pacific 
Northwest Bell, Mr. Frank was Supervisor in the electronics data processing 
area of the Comptroller’s division. At AT&T Bell Laboratories he worked in 
the TSPS laboratory. In 1975 he was designated Bell Laboratories Visiting 
Professor to Southern University (Baton Rouge, La.). Mr. Frank became 
Supervisor of the 4ESS Network Management Control Group in 1976 and has 
worked on several large software development projects relative to the domestic 
and international telecommunication markets. In 1980 he was selected as a 
Sloan Fellow by the Graduate School of Business at Stanford University. In 
1981 Mr. Frank was appointed Head of the Toll Digital Systems Development 
Department, where he worked on toll features for both 4ESS and 5ESS 
switching systems. In 1985 he assumed the position of Director of the 5ESS 
System Software Laboratory at AT&T Bell Laboratories in Naperville, Illinois. 
Member, IEEE, Eta Kappa Nu. 


OPERATIONAL SOFTWARE 1383 


Hans Oehring, B.S., 1958, Lafayette College, and M.S., 1960, Ohio University, 
both in Applied Mathematics; AT&T Bell Laboratories, 1960—. Mr. Oehring 
joined AT&T Bell Laboratories in 1960 as a Member of Technical Staff in 
1ESS system development. He was named Supervisor of a 1ESS system 
development group involved in the development of business customer services 
in 1967. In 1977 he was promoted to Head of the 1/1A ESS Software Design 
Department, responsible for field support, planning, architecture, database and 
maintenance software. He transferred to the 5ESS system project in 1980 as 
Head of the 5ESS Operational Program Department, responsible for the design 
of the operating system, data base manager, peripheral control software, 
administrative services, and the overall software architecture. He became Head 
of the 5ESS Application Maintenance and Growth Department in 1983. His 
department is responsible for the software design and development of the basic 
Integrated Services Digital Network operational and maintenance capabilities. 
The department also develops the fault-recovery software for many of the 
peripheral hardware units and provides the growth scenarios for these units. 
Member, Sigma Pi Sigma. 


L. C. Stecher, B.S., 1967, Loyola University; M.S., 1968, Northwestern 
University; Ph.D., 1972, Northwestern University, all in Applied Mathematics 
and Computer Science; AT&T Bell Laboratories, 1970—. Mr. Stecher was 
involved in the design and development of the 4ESS maintenance and call- 
processing subsystems. In 1975 he became Supervisor of the 4ESS trunk 
maintenance development effort and later supervised an exploratory effort to 
define new network services for the evolving Stored Program Controlled 
Network. In 1980 he became Head of a department responsible for development 
of software for the Traffic Services Position System. In 1982 he became Head 
of a department responsible for the development of the 5ESS Remote 
Switching Module. In 1983 Mr. Stecher took over responsibility for the 5ESS 
Project Management, Architecture, and Planning Department. This department 
is responsible for determining the feature content of future 5ESS switching 
system generics, specifying the software and hardware achitectural modifications 
necessary to develop these features, and providing the ongoing project man- 
agement for the generic development. 


1384 TECHNICAL JOURNAL, JULY-AUGUST 1985 


AT&T Technical Journal 
Vol. 64, No. 6, July-August 1985 
Printed in U.S.A. 


The 5ESS Switching System: 


Maintenance Capabilities 
By G. HAUGK, F. M. LAX, R. D. ROYER, and J. R. WILLIAMS* 


(Manuscript received November 3, 1983) 


In developing the 5ESS™ switching system, a digital switch with distributed 
control, major emphasis has been placed on reliability, quality of service to 
the customer, and efficiency of the human interface for the telephone operating 
companies. To achieve a high-reliability design for this system, a robust 
hardware/software architecture has been developed with emphasis on a net- 
working approach to functional maintenance organization. Building on this 
approach, a highly effective set of capabilities is provided for the detection and 
sectionalization of errors, and for recovery from software and hardware faults. 
Complete diagnostic aids are available, and flexible video display terminals 
provide an efficient and attractive means for telephone operating company 
personnel to interface to the system. Further, a wide range of automated, as 
well as manual, trunk and line test features are integrated into the system 
design; and interfaces to both local work stations and operational support 
systems provide a variety of options for efficient maintenance operation. 


l. INTRODUCTION 


Reliability and maintainability are of critical importance in the 
design of high-availability switching systems. Design for high reliability 
requires capabilities that provide continuity of service when failures 
or problems occur, be they hardware, software, or human induced. 
Maintainability issues center around the provision of capabilities that 
support prompt and accurate repair and control operations by the 
telephone operating company maintenance personnel (crafts people). 

In developing the 5ESS switching system, reliability and maintain- 
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ability have been integrated into the total system architecture.! In 
addition, features that support the maintenance of trunks and lines 
terminating on the 5ESS switch have been integrated into the system 
design. These include a comprehensive set of capabilities that permit 
interactive, automatic, routine, and remote testing of lines and trunks. 

The human interface has been designed for both performance and 
flexibility. Using the CRT-based Master Control Center (MCC)* and 
other optional test positions, maintenance operations can be efficiently 
performed in a manner that supports high-reliability operation in a 
user-friendly environment. 

From the operations point of view, considerable flexibility is provided 
in the design of these interfaces. For example, color is an option for 
the MCC video display terminal, and the telephone operating company 
can select one of two available human interface languages. 

Overall, the maintenance capabilities for the 5ESS switch can be 
categorized into the following five principal areas: 

1. System integrity and software recovery 

2. Hardware fault recovery 

3. Hardware diagnostic and repair aids 

4. Trunk and line maintenance 

5. Maintenance crafts people interface. 

Subsequent sections further describe these capabilities. 


Il. SYSTEM INTEGRITY AND SOFTWARE RECOVERY 


The 5ESS switch has a distributed-processing architecture that 
consists of a network of modules, each performing a variety of tasks 
autonomously. Software-recovery actions for such an architecture offer 
new challenges not encountered in previous systems. 

The software architecture is based on a strategy that only loosely 
couples the various modules. Combining fault-tolerant software with a 
robust set of automatic module recovery actions sets the stage for a 
distributed network approach to software recovery. 

The network approach to software recovery places a heavy emphasis 
on the stability and recoverability of each module. Software data- 
structure design and single-module recovery actions are major elements 
supporting system stability. These elements, coupled with recovery 
actions stimulated by a set of techniques including in-line run-time 
error detection and periodic checks of functional system components, 
lead to high reliability for both the individual modules as well as the 
total 5ESS switching system. 

This section highlights the software-recovery techniques used in the 
5ESS switch to attain a high degree of reliability. 


* Acronyms and abbreviations used in the text are defined at the back of the Journal. 
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2.1 Loosely coupled network of modules 


A solid software fault-recovery strategy is a fundamental building 
block to the reliable operation of any Stored Program Control (SPC) 
switching system. The software-recovery strategy for the 5ESS switch 
is based on localized, autonomous, module recovery. Within this 
decoupled recovery strategy, an error is confined and recovered within 
the boundary of the physical module where the error was originally 
detected. Hence, when a high-level recovery action is required in one 
module, only the module experiencing difficulty is recovered, without 
adversely affecting the operational capabilities of the other modules. 
This strategy allows normal operation to continue in the rest of the 
5ESS switch while one module is undergoing recovery, resulting in a 
minimal system outage. The 5ESS switch decoupled recovery strategy 
is in contrast to a monolithic approach wherein a high-level recovery 
action affects all of the modules, resulting in a total system outage. 
This decoupled approach to software recovery enhances the stability 
and recoverability of each module within the network, and thus 
increases the system’s overall availability by limiting error propagation 
between modules. 

The attributes of such a strategy can be compared to the classical 
network of offices in which a tandem office is used to interconnect 
several local offices, as shown in Fig. 1. Since the signaling interface 
between offices uses a standard high-level protocol, an error condition 
in one office is autonomously recovered while the remainder of the 
network continues to operate normally. The architecture of the 5ESS 
switch can be compared to the network of offices described above by 
replacing the tandem office with a Communications Module (CM), the 
local offices with Switching Modules (SMs), and adding an Adminis- 
trative Module (AM). In this network of modules, depicted in Fig. 2, 
the AM directs the CM to set up connections between the modules in 


MAINTENANCE CAPABILITIES 1387 







SWITCHING 
MODULE 










SWITCHING 
MODULE 






ADMINISTRATIVE 
MODULE 









SWITCHING 
MODULE 










COMMUNICATIONS 
MODULE 





SWITCHING ear satGrih 
MODULE a 
MODULE 







SWITCHING 
MODULE 






SWITCHING 
MODULE 


Fig. 2—5ESS switching system. 


response to call requests, while each SM provides an intelligent 
switching interface to the customer. Similar to the network of offices, 
a given module within the 5ESS switch may undergo software-recovery 
actions while the rest of the system continues to operate normally. 


2.2 Software error detection 


Reliable fault-tolerant software is an integral part of a reliable 
switching system. Fault-tolerant software should detect errors before 
they can degrade the system’s performance, permitting recovery from 
errors with a minimum degradation of performance. Faults may be 
due to crafts people’s procedural errors, hardware failures, or software 
defects. Fault tolerance is an absolute necessity if system downtime 
objectives are to be met. 

The 5ESS switch software fault-tolerant design strategy employs 
several techniques to detect, contain, and recover errors with a 
minimum impact on system operation. Specifically, this strategy em- 
bodies the concepts of software error detection, error containment, 
independent processor initialization, and interprocessor data consis- 
tency. Fault-tolerant software in the 5ESS switch is characterized by 
the following features: in-line defensive checks, recovery from interrupts, 
initialization, and escalation. 


2.2.1 Defensive checks 


In-line defensive checks are extensively used throughout the system. 
This software fault-detection mechanism consists of comparing data 
relationships, or checking for specific data values at intermediate 
points in a program. 

The objective of the defensive check is to detect software faults or 
bad data at the earliest possible time, and then to signal for recovery. 
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In this manner, faults are detected early and prevented from propagating 
throughout a module as well as throughout the system. A common 
systemwide approach is used for detecting, reporting, and recovering 
from these errors. 


2.2.2 Audits 


Reliable fault-tolerant software data-structure design is a key element 
supporting system stability. Audit programs are an essential form of 
error detection and correction within these software data structures. 
They are designed to detect, confine, and recover software data errors 
before system performance is adversely affected. Both intramodule and 
intermodule audits are interleaved with call-processing activity and 
routinely executed to ensure data integrity. In the event an error is 
detected that is so critical that normal call-processing operation cannot 
reasonably be expected to continue, an audit may be run in a special 
uninterrupted mode. These actions provide localized recovery to correct 
the error, and prevent escalation to a more severe level of recovery. 


2.2.3 Software and hardware checks 


Various types of resource checks are employed to ensure that a 
proper allotment of real time and a balanced distribution of system 
resources are provided among program clients. Such checks include 
hardware sanity-timer checks, process-activity checks, and tight-loop- 
detector checks. Additional software checks are made on resource 
availability, resource limits and throughput, and lost resources. In 
addition, several event-driven internal-hardware functional checks are 
used to detect and recover faulty communications between modules. 
An external sanity monitor is utilized as an overall backup to period- 
ically test the system’s ability to process calls. 


2.3 Initialization strategy 


Initialization levels in the 5ESS switch are hierarchical in nature. 
Each higher-level recovery action takes more severe actions. This 
recovery escalation philosophy takes advantage of the loosely coupled 
architecture to confine software-recovery actions to within a single 
module. Recovery actions initially are focused only on that portion of 
a module in which the error occurred. If unsuccessful, broader recovery 
actions are taken until eventually the entire module is initialized. 
During some high-level module initializations, it may be necessary to 
ensure interprocessor data consistency. In these cases, resynchronization 
of cross-module redundant data is performed if any inconsistencies are 
detected under both normal and recovery situations. 

The following sections provide an overview of the recovery actions 
taken at each of the levels of recovery. Although slightly different 
specific actions may be taken at each level in the AM or the SM, the 
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strategy and objectives of each initialization are the same. The various 
initialization levels within a module include return to point of interrupt, 
Single Process Purge (SPP), directed audits, selective initialization, 
and full initialization. 


2.3.1 Return to point of interrupt 


A Return to Point of Interrupt (RPI) is the lowest level of software 
initialization. It is performed automatically in response to in-line, 
program defensive-check failures, and when restarting from mainte- 
nance interrupts. Actions associated with this level include local 
initialization of user-owned global data, scheduling of deferrable recovery 
actions such as audits, and escalation to the next highest level of 
recovery if appropriate. Control flow is usually returned to the previously 
interrupted point. This level of initialization is noncall affecting. 


2.3.2 Single process purge 


The SPP level is used whenever an error is detected that is severe 
enough to make it unsafe to return to the point of interrupt. The 
primary objective of the initialization action is to restore a software 
configuration that can support resumption of normal processing. 

The initialization is usually confined to a single process entity 
within the operating system environment, such as a system process, a 
terminal process, or a demand process. The recovery actions associated 
with an SPP include killing or restarting, if appropriate, the running 
process or task, restoration of any associated global data, and recovery 
of hardware and software resources. 

Control is reestablished at a safe point. Normally, this level of 
initialization is noncall affecting. 


2.3.3 Directed audits 


Directed audits are used as an initialization action whenever incon- 
sistencies are discovered in critical data structures that prohibit 
continued normal system operation. This level is generally invoked 
from either a routine audit or a user-program, in-line, defensive-check 
failure. 

The action taken by this initialization level is to recover, in an 
unsegmented mode, enough of the data structures to ensure that 
normal system operation can resume, and to schedule on a deferred 
basis any audits that are further needed. 


2.3.4 Selective initialization 


The second highest level of initialization in any module in the 5ESS 
switch is selective initialization. This level preserves all stable talking 
calls associated with that module. 
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2.3.5 Full initialization 


The highest level of initialization in any module in the 5ESS switch 
is full initialization. This level will clear all calls from that module, 
and will restore it to normal operation regardless of the software 
configuration at the time the full initialization is invoked. The general 
strategy of this level is to completely initialize all of the memory and 
peripherals associated with that module, and then restore data syn- 
chronization with the other modules in the system. 

Before running a full initialization in the SMs, hash-sum checks are 
made over portions of memory that are backed up on the system disk. 
If any region of memory is found inconsistent with its hash-sum 
record, that region is pumped from the disk image before the main 
portion of the initialization is begun. In the AT&T 3B20D computer- 
based AM,” the full initialization level is accompanied by the UNIX 
Real-Time Reliable (RTR) operating system initialization, which results 
in a complete rebooting of all text and data portions of memory.* 

Mechanisms are provided to preserve recent changes and generic 
program updates that have not yet been committed to the system disk 
across full initializations. Any of the mechanisms for maintaining 
recent changes or program updates across initializations can be over- 
ridden by crafts person commands. This facility allows manual actions 
to remove temporary changes in the event that they may be interfering 
with the recovery of the system. 

All levels of initialization provide reports, following the initialization, 
that describe the state of the module at the beginning and end of the 
initialization, its cause, and other information useful for determination 
of the conditions surrounding the initialization. 


2.3.6 Escalation 


The escalation philosophy takes advantage of the loosely coupled 
architecture and confines software-recovery actions to within a single 
module. Abnormal events are recorded in error history tables on a 
module basis. Based upon preestablished threshold values, the escalation 
programs determine if the current error events, based on recent history 
only, warrant an escalation of recovery action to the next highest 
level. For each module there are several levels of initialization, as 
illustrated in Fig. 3, with impacts ranging from minimal to a complete 
clearing of all stable calls associated with that module. 

The escalation strategy is designed to recover the system in the 
shortest possible time with the least adverse affect on the total system. 
Furthermore, the escalation strategy also guarantees forward progress 
towards recovery. If the focused, low levels of recovery fail to recover 
normal operation to a failed module, recovery actions automatically 
escalate to more severe levels. This escalation occurs whenever a 
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Fig. 3—Switching module recovery and escalation. 


recovery action fails to complete within a predetermined time interval, 
or when failure events recur during a postrecovery time interval. 
Repeated initializations will escalate to the level necessary to recover 
the system. All critical initialization/recovery constraints are parame- 
terized to permit easy modification and fine tuning of the escalation 
strategy. 


2.3.7 Intermodule data synchronization 


A relatively small amount of SM-AM intermodule redundant data 
exists in the 5ESS switch. Whenever the AM and any SM are out of 
communication for an extended period of time, their shared data are 
resynchronized once intermodule communication has been restored. 

Intermodule data synchronization is triggered whenever a loss of 
communications occurs between an SM and the AM. The AM is 
capable of resynchronizing all SMs concurrently. 


Ill. HARDWARE FAULT RECOVERY 


The ability to recover promptly and efficiently from hardware faults 
is another requirement for meeting the reliability objectives for a high- 
availability system. In designing the 5ESS switching system, substantial 
attention has been given to hardware fault recovery—in the system 
architecture, in hardware design, and in software design. Hardware 
redundancy, configuration switchability, built-in error-detection mech- 
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anisms, and deterministic software-implemented recovery strategies 
are specific examples that are discussed in this section. 

Guiding principles in developing the 5ESS switch, as mentioned 
earlier, were to fully pursue the concepts of distributed control and 
loose coupling between system modules. These principles have also 
been vigorously followed in hardware fault-recovery design. For example, 
error detection and recovery actions for an SM are carried out in that 
module. For this example, the role of the AM is to report the recovery 
actions to the system maintenance personnel. 


3.1 Hardware considerations 


A significant part of the 5ESS switch hardware exists for the 
purpose of meeting system reliability objectives. Redundancy, error- 
detection logic, and circuitry that permits configuring around faults 
are prime examples. These are all prerequisites to attaining the 
reliability of objectives set for telecommunication switching systems. 


3.1.1 Redundancy 


Duplication is widely used in the 5ESS switch architecture to permit 
operations to continue unhindered in the presence of a hardware fault. 
Figure 4 illustrates some of the redundancy employed in the system 
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design. As can be seen, full duplication is employed for all major 
control and switching elements. In the case of the SM, redundancy is 
also carried beyond the module control to the Time-Slot Interchange 
Unit (TSIU), since it is needed to provide highly reliable operation. 
For example, in the line unit (see Fig. 5), combinations of duplication 
and redundancy are employed in achieving the required level of 
reliability. 


3.1.2 Error detection and containment 


The abilities to detect and report errors are vital parts of a hardware 
fault-recovery plan. In the 5ESS switch design, a self-checking strategy 
has been widely used in the hardware architecture. A variety of specific 
mechanisms are used, including 

1. Parity/hamming checks 

2. Operation code, address, and data validity checks 

3. Sanity timers 

4, Background-level exercise tests run by microprocessors 

5. Synchronous Data Link Control (SDLC) and BX.25 protocol 
checks for link transmissions 

6. Buffer overflow detection. 

Error containment is also an important factor in the development 
of fault-recovery systems, and further, it is an important factor in the 
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degree of “external” impact that results from a recovery action. Special 
attention was devoted to error containment in the 5ESS switch design, 
which has enabled the loosely coupled module approach to be achieved. 
To illustrate, parity checking and regeneration at various points in the 
switching network provide prompt and localized detection of errors in 
the switching path. This permits ease in identifying an offending unit, 
and, just as importantly, prevents error signals from being broadcast 
throughout the system. In turn, this allows straightforward recovery 
actions to occur without impact to the remainder of the system. 


3.1.3 Error reporting 


Several levels of error reporting are employed to notify fault-recovery 
software of errors detected in hardware operation. For the more 
significant error types, high-priority interrupt mechanisms are used. 
For less serious errors, lower-level report messages are launched to the 
appropriate module for processing. Finally, for nontime-critical events, 
error source registers (set by error detectors) are periodically polled by 
software to determine if any errors have occurred. For each unit, 
specific reporting mechanisms have been chosen to achieve a good 
balance between 

1. Impact on overall system performance 

2. Impact on the specific unit involved 

3. Economics (system cost). 

Figure 6 illustrates typical error detection and reporting schemes 
employed in the SM control and TSIU. 


3.2 Software functions and strategies for hardware fault recovery 


The 5ESS switch fault-recovery strategies and the logic for config- 
uring the system are principally contained in software. To achieve the 
loosely coupled design intent, major portions of the system’s fault- 
recovery software are resident in the administrative and switching 
modules. The AM, based on the 3B20D computer, is fully self- 
recoverable.® Similarly, the SM is designed for self-recoverability, both 
from simplex failures in the module controller and TSIU, as well as 
from failures in the SM’s peripheral units (e.g., line units, trunk units, 
and service circuits). This is achieved by having fault-recovery software 
resident in the SMs at all times. For the CM, recovery actions are 
principally orchestrated from the AM. 

A variety of hardware fault-recovery strategies are employed in the 
5ESS switch design. Unit-specific strategies cover the majority of 
faults. For these, recovery actions are invoked in response to unique 
errors, i.e., errors that trigger a specific detector that in turn implicates 
a specific unit. Another strategy, error thresholding, is commonly used 
to filter out transient errors. Other strategies, including error analysis, 


MAINTENANCE CAPABILITIES 1395 


aRaeEee GER ORE | [SANITY TIMER 
* ADDRESS DECOD 
| - ERROR CHECK | | areal 


* ALL SEEMS WELL 



















| © TIME-OUT 
fhe leet Ate J ce INTERNAL BUS PARITY) 
NETWORK 
CONTROL 
PERIPHERAL See 
INTERFACE Hh 
CONTROL BUS CONTROL MODULE 





( 

















INTERFACE | CONTROLLER TO TIME- 
TO DUAL-LINK MULTIPLEXED 
PERIPHERALS INTERFACE SWITCH 





TIME-SLOT 









PERIPHERAL INTERCHANGER 
INTERFACE 
DATA BUS MODULE CONTROL 


AND TIME-SLOT 
INTERCHANGE UNIT 













Teale See eee es 
| *PERIPHERAL INTERFACE | | * DATA PARITY 
| DATA BUS PARITY | «CONTROL PARITY | 
|  TIME-SLOT INTERCHANGER | | * FRAMING AND SLIP 

Ee eee eR ees 

(a) 
MODULE 
CONTROLLER 
MICROPROCESSOR 
NONMASKABLE MASKABLE 
INTERRUPTS INTERRUPTS 













ERROR SOURCE REGISTER 





ERROR SOURCE REGISTER 


SANITY 
TIME-OUT 




















CONTROL 
INTERFACE 
ERROR SOURCE 
REGISTER 


TIME-SLOT 
INTERCHANGER 
ERROR SOURCE 
REGISTER 


DUAL-LINK 
INTERFACE 
ERROR SQURCE 
REGISTER 


MEMORY-WRITE 
PROTECTION ERROR 






DATA PARITY ERRORS 
CONTROL PARITY ERRORS 
FRAMING AND SLIP ERRORS 


PERIPHERAL INTERFACE 
DATA BUS PARITY ERRORS 


TIME-SLOT INTERCHANGER 
RAM PARITY ERROR 


ADDRESS 
ERRORS 


ALL-SEEMS- 
WELL ERRORS 






INTERNAL BUS 
PARITY ERROR 







TIME-OUT 


(b) 


Fig. 6—Typical error-detection and reporting mechanisms for the switching module 
controller and TSI unit: (a) error detection; (b) error reporting. 


are used to handle the more complex faults. Moreover, high-level 
hardware recovery strategies are also in place to support the more 
global system-level recovery strategies discussed previously in Sec- 
tion II. 
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Provisions have also been made for handling recurrences of error 
reports for which the primary recovery strategy is ineffective. Alternate 
strategies have been provided in the 5ESS switch design to handle 
these cases. This mechanism provides an effective way to deal with 
low-probability failures, including multiple faults. 

The ability to have graceful degradation is another characteristic of 
the 5ESS switch design. This is particularly important in multiple 
fault situations involving opposite sides of the duplicated hardware 
architecture. Although infrequent, these faults could otherwise cause 
significant impact on system performance. One area where significant 
attention has been given is in the central stage of the switching 
network, the time-multiplexed switch, which is part of the CM. 

To provide telephone company maintenance personnel with ultimate 
control of the system, the ability to manually inhibit error reports and 
force specific configurations is also provided in the design. These 
capabilities override normal recovery actions and thus permit mainte- 
nance personnel to establish working configurations under highly 
unusual failure conditions. 


IV. HARDWARE DIAGNOSTICS AND REPAIR AIDS 


The purpose of diagnostic programs is to verify that circuits being 
tested function according to their requirements. If a circuit under test 
does not function accordingly, the diagnostic process should readily 
guide the user to the faulty hardware for repair. 


4.1 Objectives 


In real-time systems designed for continuous operation, diagnostics 
must be run in a time-shared noninterfering mode with the application 
software and hardware. The 5ESS switch is such a system. In this 
system it is unacceptable to deny service to communications customers 
for fault isolation, repair, or routine testing. 

Maximum fault detection of all faults is desired. While practical 
and economic constraints prevent the detection of all possible faults, 
it is clear that high coverage can be achieved by addressing testability 
at the very beginning of the design process. 

Diagnostic fault resolution is defined as the ability of a diagnostic 
program to pinpoint the location of a faulty circuit in the system. 
Upon fault detection, and when tests in a diagnostic fail, the diagnostic 
program should provide a rank-ordered list of hardware items that are 
candidates for replacement or repair. These rank-ordered lists are 
called Trouble Location Procedure (TLP) lists. In addition to removable 
circuit boards, the TLP lists may include other hardware, such as 
cables and power supplies. It is desirable that the vast majority of all 
faults encountered by operating personnel be on a TLP list. Indeed, it 
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is an objective that, in the majority of failure instances, the replaceable 
unit containing the fault be high (i.e., first or second) on the appropriate 
TLP list. 

Diagnostic run time is measured from the time a diagnostic is 
requested until the diagnostic result is available. Short run time is 
often in conflict with high fault-detection coverage and high resolution. 
It is important to note that a diagnostic that runs fast, but does not 
detect or locate many faults, does not support a short repair time. 
Diagnostics that balance all diagnostic objectives prove most useful to 
maintenance personnel. 

Measures of fault-detection coverage, fault-location performance, 
and run time can be made. This is accomplished by the examination 
of data obtained from physical fault insertion, simulation, and system 
operation, both in the laboratory and in the field. By use of these 
means, diagnostic performance is measured, improved, compared to, 
and balanced against objectives. 


4.2 Design approach 


The diagnostic subsystem of the 5ESS switch is aligned with the 
system’s high-level distributed-control architecture. The diagnostic 
software structural philosophy includes the minimization of internal 
messages to maximize system performance. Diagnosis of a given piece 
of equipment is generally performed by the nearest processor in the 
system having sufficient software capability. Diagnostics run from 
these locations tend to minimize run time and have a better ability to 
control and monitor the circuits being tested. 

The AM processor, the Foundation Peripheral Controller (FPC), 
which is part of the CM and SM processors, execute the diagnostics 
for at least one additional system component and are referred to as 
diagnostic hosts.1* The approach used in diagnosing hardware periph- 
erals associated with a diagnostic host generally depends on the nature 
of that hardware. 

A peripheral that contains no processing capability of its own is 
tested entirely by its host, from which stimuli are applied and responses 
are measured. 

A peripheral that has a microprocessor of its own, but insufficient 
software power to act as a diagnostic host, is approached in a different 
manner. Such circuits are typically diagnosed from the nearest host 
by a combination of direct tests of the peripheral-host interface, 
firmware-resident tests of additional portions of the circuit, and 
possibly down-loaded, RAM-resident tests of the remainder. 

The AM and SM processors are the major duplex processors in the 
system. The active member of a major duplex pair is generally used to 
execute the diagnostic of the other member. Diagnosis is accomplished 
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by an appropriate combination of direct tests by the active mate, 
firmware-resident self-test, and RAM-resident tests loaded from 
the mate. 

In all of the cases outlined, the technique of using only active or 
previously tested circuitry in the hardware under test is followed. 

Conceptually, diagnostic programs may be considered to be resident 
in the host processor in which they are executed. In actuality, they 
are generally loaded into a host’s memory from the system disk on 
demand under the auspices of diagnostic control software. This loading 
process is known as paging. Therefore, while a large fraction of the 
total software generic consists of diagnostic programs, only a relatively 
small amount of processor memory is required for their execution. 


4.3 Diagnostic environment 


The diagnostic environment for the 5ESS switch was designed such 
that the diagnostic program developers can concentrate on the hardware 
and the hardware interfaces being tested, as opposed to system 
software interfaces. This isolation is provided through the environment 
software consisting of diagnostic supervisors and special-purpose di- 
agnostic functions and macros. 

The diagnostic supervisor’s role includes controlling diagnostic exe- 
cution, providing hardware read/write access, managing resources, and 
preventing the diagnostics from interfering with normal system oper- 
ations. 

The Peripheral Diagnostic Language (PDL/5) was developed for the 
5ESS switch to formalize the interfaces between the diagnostic program 
and the system software. Special-purpose functions, called by means 
of corresponding macros (PDL/5 macros), allow the diagnostic to 
access hardware, use special resources, and, at the same time, isolate 
the diagnostics from the system. The language is specifically designed 
as an augmentation of the C programming language. Among other 
things, the use of the PDL/5 macros in diagnostic programs detects 
as many diagnostic coding errors as possible at compile time, and 
provides a C comment labeling for each segment and each test. This 
labeling is an aid in reading diagnostic listings and for use in the rare 
case of manual troubleshooting. 


4.4 Diagnostic structure 


Typically, there is a unit diagnostic for groups of major functions 
contained on one or more circuit boards. The unit diagnostics are used 
to diagnose the hardware set that has been removed by fault recovery 
because of a problem. This hardware set is called a repair group, 
because if any piece of hardware in the group fails, the entire set of 
hardware is removed from service for diagnosis (repair). In some 
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instances, the repair group and the unit diagnostic are “identical” 
(e.g., the FPC), while in others, the repair group is diagnosed by the 
use of several subunit diagnostics. 

Each diagnostic consists of several diagnostic phases. A typical 
phase diagnoses a set of functionally related hardware on one or more 
circuit boards. The following criteria are among those used to determine 
what tests are to be included in the same phase: 

1. Each phase should contain tests that are associated by virtue of 
some common property. A common property can be physical, such as 
a circuit board, or logical, such as when a phase tests a circuit 
subfunction. 

2. Phases may be run independently, and, because of this, they are 
designed so that the results are independent of the order in which 
they are run. 

3. Phases should be homogeneous in their use of helper circuits so 
that tests requiring dissimilar helpers are not in the same phase. A 
helper circuit is any other circuit used to help diagnose the unit that 
is under test. Use of these criteria ensures that tests requiring unrelated 
resources are not skipped by keeping related tests together. 

Each diagnostic phase is composed of segments. A segment is defined 
to contain the set of tests necessary to test a single board function or 
operation. Diagnostic segments have system-dependent requirements 
such as run-time limits, real-time breaks, and critical region require- 
ments. Specific segment execution time limits are restricted to ensure 
that diagnostic execution does not impact other system activities, e.g., 
call processing. 

Each segment is composed of one or more tests. A test is a minimum 
exercise that produces observable results. 


4.5 Routine exercises 


The 5ESS switch diagnostic software has an important capability 
known as Routine Exercise (REX). The REX capability allows oper- 
ating personnel to schedule periodic diagnostic and other testing of 
the system hardware. By this means, the office equipment is tested 
routinely to detect latent faults before they can affect service. 

The implementation of the REX capability utilizes the 5ESS switch 
distributed architecture to an advantage. Once started by an AM 
process, the per-processor processes diagnose their hardware units 
autonomously. 

A scheduling table in the AM is used for these purposes. Using this 
table, operating personnel can, if desired, specify or change the days, 
the times of day, and the length of time REXs are to be run on the 
various modules comprising the system’s hardware. Duplicated circuits 
are tested and switched, and simplex circuits are tested and restored 
to active service if the diagnostic passes. When faults are encountered, 
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diagnostic results are both printed out and displayed. Also, as testing 
progresses, each control process maintains a table of statistics including 
the numbers of circuits of each type tested, passed, and failed. Once 
each day, or, asynchronously, on demand by maintenance personnel, 
a summary report on the current results from REXs can be printed 
out and displayed. 


4.6 On-line trouble location 


In the 5ESS switch, TLP lists are provided on-line immediately 
following diagnostics to the various output locations. These output 
locations include the MCC at the switch, operating company switching 
control centers, and, if needed, at support centers at AT&T Technologies 
and AT&T Bell Laboratories. A TLP list is provided by the diagnostic 
program when it detects a failure of one or more of its tests. 

In the 5ESS switch, the TLP list generation is an integral part of 
the diagnostic program design. The designer uses special PDL/5 
macros to specify how the TLP hardware list is to be built and 
adjusted dynamically as the diagnostic progresses through its sequence 
of tests. With this approach, the TLP capability can easily be kept in 
step with diagnostic and hardware evolution. 

This on-line approach in the 5ESS switch is convenient for operating 
personnel with switch maintenance responsibilities. Because of the 
extensive use of Large-Scale Integration (LSI) circuitry, the typical 
unit or circuit being diagnosed is composed of only a few circuit boards. 
In fact, the majority of the hardware is covered by individual diagnostics, 
where the reconfigurable unit or circuit is contained on a single board. 
In many cases, the suspect-board list contains the single board and 
one or two of the boards with which it interfaces. In these cases, the 
diagnostic designer need only be concerned with the optimum rank 
ordering of the two or three boards on the TLP list. A very large 
percentage of the expected hardware faults are first on the rank- 
ordered TLP lists. 


4.7 Typical output 


A typical input request to run a diagnostic and a typical failure 
output response are shown in Fig. 7. 
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4.8 Additional features and capabilities 


The diagnostic system for the 5ESS switch has many desirable 
features and capabilities beyond those discussed in this brief section. 
Several examples follow. 

1. More than one diagnostic can be run in an interleaved time- 
shared mode concurrently in an individual SM. This is in addition to 
the capability of running diagnostics simultaneously in several SMs. 

2. Simple visual displays of system status and craft interfaces are 
provided. User-friendly, menu-driven selections are displayed to assist 
the craft in maintaining the switch. 

3. Diagnosis of links between major units (e.g., SMs and time- 
multiplexed switches) is provided for routinely and on demand by 
cooperative use of diagnostics at each end, plus link-specific diagnostics. 

4, Testing of the solid-state line concentrators is accomplished using 
two programs: the concentrator diagnostic and a network fabric test 
program. The role of the concentrator diagnostic is to determine the 
health of the concentrator as a whole. The role of the fabric test 
program is to verify that each and every crosspoint and link works 
properly and that no shorts or opens exist. The fabric test is run 
routinely or on demand with the concentrator in service and coexists 
with call processing. 


V. TRUNK AND LINE MAINTENANCE 


Maintainability considerations for trunks and lines are also important 
factors in the design of telecommunications systems. Automatic detec- 
tion of faults, administration of service status, and facilities for running 
tests and making measurements are capabilities required for the 
maintenance of trunks and lines. Over the years, a number of methods 
have been employed in this area and many are currently in use. Some 
methods depend on capabilities either built into or appliqued onto a 
switching system, while other methods center on remoting of main- 
tenance functions. Centralized maintenance approaches are also 
widely used. 


5.1 Facilities 


For the 5ESS switch, a complete set of trunk and line maintenance 
facilities have been integrated into the system design, and interfaces 
have also been provided for remote testing. The goal is to provide 
flexibility to the telephone operating companies to best meet their 
individual needs. 

The principal hardware parts of the 5ESS switch related to trunk 
and line maintenance are shown in Fig. 8. Coupled with software 
control, these provide a complete feature set and flexibility for both 
local and remote maintenance operations. 
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The Trunk Line Work Station (TLWS) is integrated into the MCC 
of the 5ESS switch. As shown in Fig. 9, key TLWS facilities include 
a CRT video display terminal, a receive-only printer, a key telephone 
set for voice and monitor connections, and a test access unit with ac 
and dc jacks that provide access for testing with portable test equipment. 
The CRT terminal at the TLWS is the principal human interface for 
trunk and line testing. For larger offices, up to six supplementary 
TLWSs can be equipped as needed. 

The Transmission Test Function (TTF), via switched digital Pulse 
Code Modulated (PCM) access, provides all capabilities needed for 
voice frequency testing. Tone sources and detectors, power and noise 
measurement capabilities, and features needed for a variety of standard 
test lines [100, 102, 104, Remote Office Test Line (ROTL) and Touch- 
Tone signaling test lines] are incorporated in the TTF design. 

Metallic access for trunk and line testing is provided by the Metallic 
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Service Unit (MSU). In addition, the MSU hardware contains the 
capabilities needed for Automatic Line Insulation Testing (ALIT). 

The Directly Connected Test Unit (DCTU) is used for testing where 
metallic access is needed. A variety of testing capabilities are provided, 
including foreign Electromotive Force (EMF), resistance, capacitance, 
and coin station tests. 

The TTF, MSU, and DCTU units are resources shared across SMs 
in the 5ESS switching system. 


5.2 Trunk and line test features 


Using the hardware facilities described above, a comprehensive set 
of test features are provided by 5ESS switch software. Part of these 
features permit maintenance personnel to interactively perform tests 
at the video display terminal of the TLWS. To illustrate, maintenance 
personnel can, using convenient commands, request specific line/trunk 
accesses, tones, and measurements (e.g., voltage, noise, resistance, and 
capacitance). Results are quickly displayed on the terminal. 

A standard set of automated test capabilities are also integrated 
into the system design. These include the standard 100 series test 
lines and test calls (e.g., milliwatt, and two-way noise, and loss 
measurements) and ALIT. These automatic test capabilities permit 
maintenance personnel to request specific tests to be run in a prepack- 
aged fashion without the need for any human interaction. Removal 
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from service, sequencing of tests, and restoral to service are all 
accomplished automatically by the associated trunk and line mainte- 
nance software, without the need for any manual intervention. Should 
maintenance personnel in the course of testing remove from service a 
significant number of trunks within a trunk group, alarms are activated 
to aid in protecting office performance. 

Routine test capabilities built into the 5ESS switch design provide 
an efficient detection mechanism for trunk and line problems. These 
tests are run periodically with no human involvement. For trunks, the 
Automatic Progression Testing (APT) feature is provided. Tests to be | 
automatically run can be prespecified by the telephone operating 
company and can be selected from the set of operational tests built 
into the 5ESS switch design, i.e., signaling capability tests. For lines, 
ALIT tests are similarly run. For flexibility, the starting time and 
duration of routine tests can be scheduled by the telephone operating 
company in order to best coincide with an office’s nonbusy period. 
Protection is again provided to prevent routine test software from 
automatically removing an excessive number of trunks within a single 
trunk group. 


5.3 Trunk and line status 


Administrative software is provided to efficiently and reliably handle 
the maintenance status of trunks and lines terminating on a 5ESS 
switch. Call and carrier failure events as well as any failures detected 
during routine tests are reported to this software for appropriate 
processing. High and wet, blocked, and power cross lists are maintained, 
and the status of the included lines and trunks are supervised in order 
to return them to service when the problem is removed. Capabilities 
are also provided at the TLWS for querying and changing the status 
of lines and trunks. 


5.4 Remote facilities 


As shown in Fig. 10, flexibility is provided in the 5ESS switch to 
interface with both the traditional and newer remote maintenance 
facilities. For both trunks and lines, the test capabilities available on 
the TLWS CRT terminal are also available at the serving Switching 
Control Center (SCC). For trunk testing, the 5ESS switch also 
provides integrated interfaces to the Centralized Automatic Reporting 
On Trunks (CAROT) system and the new Central Trunk Test 
Unit (CTTU). The CAROT operations support system provides, on a 
centralized basis, the means for initiating and evaluating routine 
transmission tests on trunks. This capability is fully supported by the 
5ESS switch with its integrated ROTL capability. The CTTU provides, 
on a dial-up basis to the 5ESS switch, the ability to run tests on 
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Fig. 10—Trunk and line maintenance remote interfaces. 


requested trunks and lines. The 5ESS switch is also compatible with 
the Trunk Maintenance Package (TRUMP) capability provided in the 
No. 2 System Control Center System (SCCS) System located at an 
SCC. TRUMP monitors trunk error messages, performs error analysis 
functions, requests appropriate trunk tests to be run at the 5ESS 
switch, and has the ability to request removal from service of any 
failed trunk. 

For line maintenance, provisions are made for testing remotely from 
customer locations and from remote centers. From the customer 
premises, tests such as Touch-Tone signaling, station ringer, and 
connections to an open circuit or coin station test line can be made. 
For the remote repair service bureau, 5ESS switch interfaces are 
provided for testing from a Local Test Desk (LTD) or from the 
Mechanized Loop Testing (MLT) System. ALIT tests can also be 
requested from the repair service bureau. 
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5.5 Flexibility 


The trunk and line maintenance design for the 5ESS switch is 
inherently flexible. With the basic testing facilities integrated into the 
system architecture, provisions are made for a comprehensive set of 
interactive, automatic, and routine test capabilities. Remoting is a 
natural ability with flexibility in interfacing to a variety of external 
systems and facilities. The video display terminal-based TLWS offers 
a user-friendly interface that also provides substantial flexibility for 
future developments. 


VI. MAINTENANCE CRAFT INTERFACE 


Maintenance activities in the 5ESS switch are controlled via a 
modern, user-friendly craft interface system. The craft interface is 
built from basic components provided by the 3B20D computer craft 
interface package® enhanced with specific craft programs for the 5ESS 
switch. The crafts people maintain the 5ESS switch from work stations 
supported by the AM. This architecture centralizes and consolidates 
the craft interface while permitting effective maintenance of the loosely 
coupled elements of the 5ESS switch architecture. When the crafts 
people need access to a terminal anywhere in the office, interframe 
wiring permits access from a work station at a remote site. 


6.1 System architecture 


Work stations in a 5ESS switch office may contain both a video 
display terminal with keyboard and a hard-copy Read-Only Printer 
(ROP). The main work station is called the Master Control Center 
(MCC). This work station is the primary interface to the switch, and 
consists of a video display terminal, a ROP to print a paper copy of 
all major system events, and trunk and line maintenance features as 
discussed in Section V. A view of a typical MCC position is shown in 
Fig. 9. Other work stations that may be equipped in an office are for 
recent change, multiple Trunk Line Work Stations (TLWSs), and a 
belt-line terminal to assist crafts people in larger offices. All of these 
work stations may use video display terminals. 

Since a large number of 5ESS switches will be remotely maintained, 
an interface to the Switching Control Center (SCC) is provided which 
allows MCC control functions to be performed remotely. For reliability, 
the links to the SCC are duplicated and use the BX.25 protocol. 


6.2 Video display terminal 


The heart of the 5ESS switching system’s craft interface is the 
video display terminal. Several different terminals are supported that 
may be either black and white or color. The video display terminal in 
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REGION 1 SYS EMER CRITICAL MAJOR MINOR BLDG PWR BLDINH CKTLIM SYS NORM 
OVERLOAD SYS INH CU CU PERPH OS LINKS QRSQJ Mscs/tms~= = MIsc 

REGION 2 CMD: ——————1010-SM 01 LIM-MCTSI/DLI 
ENON ES TO TMS 0 TO TMS 1 MODE: 


200 MCTSI 0 CKT OOS 
201 MCTSI 1 
202 BTSR 


RESTORE 


300 MCTSI 0 
301 MCTSI 1 
302 BTSR 






REGION 3 DIAGNOSE 


500 MCTSI 0 510 DLI 0 
501 MCTSI 1 511 DLI 1 


MCTSI 7 %& 1 
ACT oos 
SWITCH 


400 MCTSI 





BTSR UNEQ 


REGION 4 


Fig. 11—Video display regions. 


the 5ESS switch combines the capabilities of the primary I/O device 
and the status display and control panels of previous systems to 
minimize cost and provide flexibility. 

To accomplish all of these functions, the video display unit screen 
is divided into four separate regions or windows (see Fig. 11). The first 
window contains a high-level system summary status as well as system 
summary alarm levels. This display provides a constant high-level 
picture of the status of the switching system. 

The second window is the system command area, which is reserved 
for entering abbreviated system commands called pokes, as described 
below. These numerical pokes are used to change the displays or to 
execute menu commands. 

The third window is the display area. This area can be used for 
several purposes. In many displays, it is used to give detailed status of 
specific hardware units. These pages use block diagrams to represent 
the various hardware subsystem units. Blocks in the diagram are 
labeled with the name of the units and their system states. Connecting 
lines represent the functional relation between units in the diagram. 
Color or backlighting and flashing are used to highlight status infor- 
mation. Most pages also contain a menu of commands that can be 
executed to change the state of units on the page. The commands are 
invoked by multiple-digit pokes that are entered from the keyboard in 
the system command region. 
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SYS EMER CRITICAL MAJOR MINOR BLDG/ PWR BLDG INH CKT LIM p@aieliy 


OVERLOAD SYS INH cu CU PERPH OS LINKS SM MSGS/TMS MISC 
CMD: a 100- PAGE INDEX 
USE EA DISP FUNCTION KEY TO DISPLAY EAI PAGE 
100 PAGE INDEX 117 IOP 0 & 1 160 TRUNK & LINE MAINT 
101-104 NOT ASSIGNED 
105 BLDG/PWR & ALARM CONTROLS 119 MISC ALARMS 190 C/D UPDATE 
106 BLDG/PWR & ALARM CONTROLS 120 MESSAGES 191 OS STATUS PAGE 
107 CIRCUIT LIMIT 121 MICU 0 6 1 197 CUTOVER 
108 NOT ASSIGNED 122 TMS 0 198 ODD RCV 
109 OVERLOAD 123 TMS 1 (NOT FOR USE BY SCC) 
110 SYSTEM INHIBITS 124 MSGS 0 199 ECD/SG RCV 
111 CU, CU PERIPHERALS 125 MSGS 1 (NOT FOR USE BY SCC) 
112 CU, CU PERIPHERALS 126 LOGICAL LINK MAP 
113 OS LINKS 127 MTIB STATUS 1950 PROG UPD MAINT 
114 EQUIPPED SM STATUS SUMMARY 1960 BWM INSTALLATION 
115 MSGS/TMS SUMMARY 130 NM EXCEPTION 1999 NO. 5 STATES 
116 MISCELLANEOUS 131 HARDWARE CALL TRACE 


Fig. 12—Page index video display. 


The fourth region on the screen is reserved to input messages to 
the system and to display system output messages. Input and output 
messages are formatted in either the conventional syntax used for 
AT&T Technologies electronic switching systems or the International 
Telegraph and Telephone Consultative Committee (CCITT) MML. 
The customer has the choice of which language to use on a per- 
office basis. 


6.3 Controlling the 5ESS switch 


Figure 12 shows one of the high-level MCC displays for the 5ESS 
switching system. This display (page 100) is the page index, which 
contains a reference list of all pages available to the crafts person for 
displaying status of any part of the switch. The SYS NORM indicator 
at the top of the display signifies that all hardware units are in service 
and are operating normally. 

To illustrate how crafts people would use these displays to control 
the system, assume that a trouble exists in one of the switching 
modules. The crafts person would be given a high-level view of this 
problem via the SM summary indicator in region 1 of the CRT screen. 
At this point, the page index could be used by the crafts person to 
step through the display hierarchy to display increasingly more infor- 
mation about the trouble. By entering 114 in the system command 
area of the page, summary status information for all equipped SMs 
can be displayed (see Fig. 13). This display points to a circuit out-of- 
service condition in SM 1. Instructions on this page inform the crafts 
person of subsequent commands to be entered. In this case, the 
command 1010, 1 would cause more detail about SM 1 to be 
displayed. As indicated in Fig. 14, SM 1 has a problem with the 
duplicated Module Controller Time-Slot Interchanger/Dual-Link In- 
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SYS EMER CRITICAL MAJOR MINOR BLDG PWR BLD INH CKT LIM SYS NORM 


OVERLOAD SYS INH CU CU PERPH OS LINKS MSGS/TMS MISC 
CMD: ———-114-EQUIPPED SM STATUS SUMMARY 


DISPLAY SM 
1000,X SM X STATUS 


1800,X SM X INH & RCVY CONTROL (FOR ISOLATED/INIT) (DO NOT USE,X FROM SCC) 
EQUIPPED INTERFACE MODULES 










Fig. 13—Status summary display for switching modules. 


terface (MCTSI/DLI) complex. At this point, the command 1010 
would cause this complex’s complete status to be displayed. Figure 11 
shows that the specific hardware trouble is in MCTSI 1. 

Using automatically generated trouble-locating information provided 
on the ROP by system diagnostics, crafts people would locate and 
replace the faulty circuit board. After the repair is completed, a single 
menu poke command will cause the 5ESS switch software to retest 
the hardware and automatically restore normal operation if all tests 


SYS EMER CRITICAL MAJOR MINOR BLDG PWR’ BLD INH CKT LIM SYS NORM 
OVERLOAD SYS INH CU CU PERPH OS LINKS SM MSGS/TMS MISC 
CMD: 1000-SM 1 LIM STATUS 


DISPLAY FOR SM X 

1800,X INH & RCVRY CNTL 
1010,X MCTSI/DLI 
102Y¥,X LU Y CONCEN 
103Y,X LU Y SG 0 
104Y¥,X LU Y SG 1 
105Y,X TU Y SG 0 
106Y,X TU Y SG l 
107Y,X DCTU yY 
1080,X LDSU SG 0 
1090,X LDSU SG 1 
110Y,X GDSU Y SG 0 
111Y¥,X GDSU Y SG l 
112Y¥,X DLTU Y 
113Y,X MSU Y SG 0 
114Y¥,X MSU Y SG 1 (DO NOT USE ,X 
115Y¥,X DCLU Y FROM SCC) 


INH & RCVRY CNTL MODE: CKT OOS 


FAN ALARM 


FUSE ALARM 


sc l 
CONCEN | CONCEN | CONCEN | CONCEN | CONCEN 


Tu 0 DCTU 0|GDSU 0} MSU O |} DCLU 0jCLTU 0 


SG 0 SG 0 SG 0 
SG l sc l sc l 






Fig. 14—Switching module status display. 
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pass. The successful execution of these tests would result in the 
MCTSI being restored to the active state. 

Experienced office crafts people could have immediately entered the 
1010, 1 command to display the status of the MCTSI/DLI complex, 
since automatically generated reports on the ROP would have pointed 
directly to this complex. Thus, the hierarchy of displays allows all 
crafts people, from the inexperienced to the experienced, to be guided 
through simple commands to the exact trouble. In this way, all 
maintenance situations can be resolved quickly. 


6.4 Trunk line work station capability 


As described in Section V, the TLWS provides the capability for 
performing trunk and line maintenance tasks at a 5ESS switch office. 
In many earlier systems, these tasks were performed using a specially 
designed hardware panel. The 5ESS switching systems, however, 
utilize standard video display terminal-based work stations to perform 
the TLWS function. The MCC includes full TLWS capabilities, and 
the MCC, remoted through the SCCS, also includes TLWS features. 
For large offices, up to six supplementary TLWSs can be equipped. 


6.4.1 Base TLWS menu 


An interactive TLWS task is initiated and controlled by the crafts 
people through a base menu referred to as a test position. There are 
eight test positions so that up to eight interactive tasks can be 
simultaneously in progress. The test position menus are simultaneously 
available at all TLWSs. A crafts person can choose to have more than 
one task active at a given work station. However, only one test position 
menu is displayed on a TLWS CRT at a time. The crafts person can 
move from task to task by entering commands to change the test 
position currently displayed. Each test position is kept up to date with 
the status for its task whether or not it is currently displayed. 

Figure 15 shows an example of a test position menu page. At the 
top, in the system summary alarm region, are office critical indicators 
common to all MCC pages. In the general display area, the upper 
portion of the display shows test parameters and task status indicators. 
Sufficient information is displayed to allow the craft to control and 
follow the progress of any task. 

The lower portion of the test position display area is used to display 
menus that give instructions and commands for all TLWS interactive 
task capabilities. Figure 15 shows page 170 displayed in this area. This 
menu gives an index of the other menus that can be requested for 
display in this area. The menus are listed in three groups corresponding 
to the three steps of a task. These include entering test parameters, 
requesting connection of a line or trunk to test equipment, and finally, 
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SYS EMER CRITICAL MAJOR MINOR BLDG PWR BLD INH CKT LIM Bx@#iye 
OVERLOAD SYS INH cu CU PERPH OS LINKS SM MSGS/TMS MISC 
CMD: 170 OK 161 - TEST POSITION 1 

IN PORT TALK MNTR E M_ RING ROH 

PROG acc 

POSITION DATA STABLE CONDITIONS RESULTS 
PORT: TYPE ACC: 
TYPE: FUNCTION: 
JACK: 
OPDN: 
FREQ: 
LEVL IN PROG ACK: 
170 - TEST MENU INDEX 

TEST DATA MENUS TEST ACCESS MENUS: TRANS TEST MENUS: 


171 POSITION DATA 172 TLLWS JACKS 177 MEASUREMENT 
173 MNTR BUSY TRK/LINE 178 SEND TONE 
174 TRANS TEST MET MEAS MENUS: 
175 METALLIC MEAS 176 METALLIC TESTS 


Fig. 15—Sample test position page for TLWS. 


the execution of specific tests. For example, instructions for entering 
test parameters are displayed with command 171. The crafts people 
need not call up these displays if they are familiar with the menu 
commands. A TLWS task command can be used when a test position 
is on the video display whether or not the menu containing the 
command is currently on the display. 


6.4.2 A sample TLWS task 


The following example shows how a crafts person would check for 
foreign voltage on a line. First, the crafts person would enter the 
directory number of the line to be tested in the command area of the 
screen. In this example assume the directory number of 357-0001. 
After being accepted by the system, this information is redisplayed 
under POSITION DATA in the center screen area (see Fig. 16). Next, a 


SYS EMER CRITICAL MAJOR MINOR BLDG PWR- BLD INH 


CKT LIM §p@eteu 


OVERLOAD SYS INH CU CU PERPH OS LINKS SM MSGS/TMS MISC 
CMD: 176 OK 161 - TEST POSITION 1 
IN TALK MNTR E M_ RING ROH 


PORT 
ACC 

POSITION DATA 
PORT: 3570001 


PROG 
STABLE CONDITIONS RESULTS 


TYPE ACC: MET MEAS 


TYPE:LINE — DN FUNCTION: 

JACK: 

OPDN: 

FREQ: 

LEVL: IN PROG ACK: 

176 - METALLIC TESTS 

REQUEST: REQUEST: (COIN LINE): REQUEST (LINE): ADDL CMDS: 

952 FEMF 964 HOME TOTALIZER 956 DIST TO OPEN 900 RELEASE 


953 RESISTANCE 
954 CAPACITANCE 
955 AV,DV,Ko,uF 


965 DETECT COIN 
966 COLLECT COIN 
967 RETURN COIN 


957 RNGR COUNT 905 PRNT RESULTS 


(MENU 175) 


Fig. 16—TLWS display page with setup for metallic testing. 
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SYS EMER CRITICAL MAJOR MINOR BLDG PWR BLD INH CKT LIM Bye fifeliiyt 


OVERLOAD SYS INH CU CU PERPH OS LINKS SM MSGS/TMS MISC 
CMD: 952 OK ———— 161 - TEST POSITION 1 
IN ee TALK MNTR E M_ RING ROH 
PROG 
POSITION DATA STABLE CONDITIONS RESULTS 
PORT: 3570001 TYPE ACC: MET MEAS OC VOLTAGE (VOLTS) 
TYPE: LINE-DN FUNCTION: AC bc 
JACK: TG 0 0 
OPDN: RG 0 0 
FREQ: TR 0 0 
LEVL: IN PROG ACK: 
176 - METALLIC TESTS 
REQUEST: REQUEST (COIN LINE): REQUEST (LINE): ADDL CMDS: 
952 FEMF 964 HOME TOTALIZER 956 DIST TO OPEN 900 RELEASE 
953 RESISTANCE 965 DETECT COIN 957 RINGR COUNT 905 PRNT RESULTS 
954 CAPACITANCE 966 COLLECT COIN (MENU 175) 


955 AV,DV,Ko,uF 967 RETURN COIN 


Fig. 17—TLWS display page with metallic testing results. 


connection between the measurement hardware and the line is requested 
with the appropriate command in the command area of the screen. 
Figure 16 shows the display after the crafts person has completed this 
activity by indicating the connection to measurement hardware. The 
PORT ACC indicator is also backlit to remind the crafts person that a 
connection is in place. As also shown in Fig. 16, page 176 contains a 
list of measurements that can now be requested. Finally, the crafts 
person requests a voltage measurement, as shown in Fig. 17, by 
entering the appropriate system command. The requested measurements 
are displayed under RESULTS. Note that the ac and dc voltages in the 
tip-to-ground, ring-to-ground, and tip-to-ring configurations are nor- 
mally displayed and dynamically updated until another measurement 
is requested. 


6.5 Flexibility 


Every effort has been made in the design of the 5ESS switch craft 
interface to make it easy and efficient to use. The use of the video 
display unit as a combination I/O device and display panel puts all 
critical office information in one place, decreasing the incidence of 
errors. 

The use of windows on the display screen allows the crafts person 
to see both overall system status and the status of a particular 
subsystem simultaneously. The use of graphics to depict hardware 
units and the connectivity between hardware units enables the crafts 
person to instantly understand the impact and scope of an equipment 
outage. Color (as an option) has been used to highlight system status 
in a natural, intuitive way. For example, green indicates in-service 
units and red indicates out-of-service units. 

The use of a single soft terminal for many functions reduces the 
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initial cost of the system and makes it easier and cheaper to implement 
new features. In previous systems, new keys and lamps were required 
in addition to system software to provide new features. With the 5ESS 
switch, only new software is normally required. The use of terminals, 
rather than dedicated keys and lamps, also allows easy remoting of 
these functions. Finally, the use of pokes to replace wordy input 
commands reduces the amount of typing the crafts person must do, 
increasing efficiency and reducing the number of errors made. 


Vil. SUMMARY 


With the described maintenance capabilities, the 5ESS switching 
system is fully capable of providing the highly reliable service demanded 
of switching nodes in telecommunications networks. The system 
maintenance features provide a friendly interface for telephone oper- 
ating company personnel that in turn further supports the reliability 
of the system and its associated trunks and lines. Building on the 
distributed processing concept inherent in the 5ESS switch design, 
maintenance actions are focused within an individual module, thus 
minimizing perturbations to the overall system. This loose coupling 
approach is a key ingredient in providing the 5ESS switching system’s 
resiliency to malfunctions, be they induced by hardware, software, or 
human procedural errors. Further, the coordinated maintenance func- 
tions are capable of handling multiple failures and severe malfunctions. 

Substantial flexibility is provided in the 5ESS switch design for the 
telephone operating companies and for system extensions. Interfaces 
are provided to a wide variety of operations support systems, and an 
integrated set of capabilities is provided for all aspects of maintenance. 
Thus, the 5ESS switching system is well suited for all applications 
ranging from stand-alone installations to offices remotely maintained 
on a centralized basis. This flexibility, coupled with the fault resilience 
and user-friendly maintenance capabilities described in this article, 
contributes significantly to making the 5ESS switching system an 
outstanding choice for telecommunications switching applications. 
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This paper gives a general description of the 5ESS™ switch hardware design. 
A significant amount of new hardware, including numerous very-large-scale 
integration circuits, microprocessors, signal processors, and memory devices, is 
used in the 5ESS switch design to accomplish its operational and maintenance 
design objectives. By adhering to the distributed and modular architecture in 
all the hardware designs, the incorporation of advancing technologies and new 
functionality is accomplished with ease. 


Il. INTRODUCTION 


The 5ESS switch hardware architecture is composed of the Admin- 
istrative Module (AM),? one or more Switching Modules (SMs), and 
a Communications Module (CM) as major system elements. Control ° 
of the office is distributed between the AM, which consists of a single 
AT&T 3B20D computer complex, and one or more SM processors. 
Communication among all these processors is performed by the Message 
Switch (MSGS) contained in the CM. Switching in the office is 
performed with a time-space-time Pulse Code Modulation (PCM) 
digital switching network. This network consists of a Time-Slot 
Interchanger (TSI) in each SM and a single Time-Multiplexed Switch 
(TMS) within the CM. The TMS, MSGS, and SMs are interconnected 
with high-speed optical-fiber links that carry network data, control 
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messages, and timing information. Interfaces to lines, trunks, and 
pair-gain systems are provided by a variety of digital and analog 
interface units. Numerous other circuits, such as the Signal Processor 
(SP), Digital Service Unit (DSU), and Metallic Service Unit (MSU) 
provide the resources and functionality necessary for call processing 
and maintenance of the office. SMs can be located up to 125 miles 
from the office, and connected by T-carrier facilities. 

The hardware design, which used sophisticated machine aids exten- 
sively, has taken advantage of many technological advances. A new 
high-voltage Gated-Diode-Crosspoint (GDX) technology is employed 
in a solid-state, low-cost, and efficient line concentrator. Very large 
scales of integration are used in 64K-bit memory chips, custom logic, 
digital signal processing, and time-slot interchanging. A single-chip 
codec/filter is employed. Optical-fiber links pioneer an interframe 
interconnection media. Extensive use is made of microprocessors to 
realize the design of the 5ESS switch’s distributed processing archi- 
tecture. 

The major hardware design objectives included a highly reliable 
system, functionality for numerous switching applications, the ability 
to accept gracefully the introduction of new technology and low cost. 
In addition, minimizing power consumption and floor space and 
providing for short installation intervals are included as design ob- 
jectives. 

The physical design of the 5ESS switch is covered in a compan- 
ion paper.’ 


Il. CONTROL STRUCTURE 


The switching network of the 5ESS switch is controlled, as shown 
in Fig. 1, by the AM and the SM. The AM performs the switching 
network path-selection function, whereas the SM performs most of 
the call-processing functions. Control information among the processors 
within these modules is communicated via messages that are transferred 
from the sending processor to the receiving processor by the MSGS. 
Messages that originate or terminate at the SM processor are trans- 
mitted by the MSGS over optical-fiber links. 


2.1 Message switch 


All interprocessor message transfers are performed by the MSGS. 
For a message to be transferred from one SM processor to another, 
the originating processor, illustrated in Fig. 2, transmits the message 
on a dedicated control time slot over its Network Control and Timing 
(NCT) link to the TMS. The message is switched from the TMS onto 
another NCT link that connects to the MSGS. Within the MSGS, an 
MSGS peripheral controller known as the module message processor 
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Fig. 1—5ESS hardware architecture. 
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Fig. 2—Message-switch interprocessor communication. 
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receives the message and, with the help of the MSGS controller, 
transfers the message to the dedicated control time slot of the 
destination SM processor. If the message is destined for the AM, the 
MSGS controller transfers the message from the module message 
processor to the AM over a high-speed serial bus. 

In addition to the messages associated with normal operation of the 
switch, the MSGS is designed to transfer large quantities of bulk data 
and program text from the AM to an SM processor. A pump peripheral 
controller is used for this operation. The effective data rate of this 
type of transfer is 192K bytes per second. At this data rate an SM 
processor can be loaded with 4M bytes of program text and data in 
about 40 seconds (including protocol overhead time). 

The MSGS is also capable of transferring special maintenance 
messages from the AM to an SM processor. These messages, known 
as processor-intervention messages, travel through the MSGS in 
parallel with normal messages and are sent by the AM to force the 
SM processor into a particular state. 

Messages from the AM that control the operations of the MSGS 
can be transferred over the high-speed serial bus to the MSGS con- 
troller. Depending on the type of message, either the MSGS controller 
will be the destination of the message, or an MSGS peripheral 
controller will be the destination. Control messages from the MSGS 
controller or an MSGS peripheral controller to the AM can also be 
transferred. 

One specific MSGS peripheral controller, known as the foundation 
peripheral controller, processes AM control messages that are destined 
for, or originate from, the network clock, the TMS, and the MSGS’s 
message and link interface circuitry. The foundation peripheral 
controller communicates with the network clock, the TMS, and the 
message and link interfaces over a standard dedicated bus known as 
the control and diagnostic access link. 


2.1.1 Message-switch controller 


The MSGS controller is designed around four bit-sliced micropro- 
cessor chips. The design includes circuitry to interface with the AM’s 
dual serial channel that allows direct memory access transfers of data 
between the AM’s processor and the MSGS controller. 

Also included in the design is a microprocessor I/O bus. This bus 
allows the MSGS controller to communicate via direct memory access 
with up to 14 MSGS peripheral controllers that may be handling 
message traffic for up to 48 SM processors. 

Up to 5 million, 30-byte messages can be handled per hour by this 
design. Microcoded algorithms are used to achieve this message 
throughput. The design includes nearly nine thousand 40-bit in- 
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structions of microcode. About one-half of these instructions are 
for maintenance functions and the rest are for message-processing 
functions. 


2.1.2 Message-switch peripheral controllers 


There can be a total of 14 MSGS peripheral controllers equipped in 
the MSGS. One of these is the foundation peripheral controller and 
another is the pump peripheral controller. The remaining 12 controllers _ 
are module message processors that are available for communication 
with SM processors. Each of these 12 module message processors 
handles eight BX.25 links. To provide interprocessor communication 
with high reliability, the entire complex of 14 MSGS peripheral 
controllers is duplicated and four BX.25 links (two from each duplicated 
side) are interconnected for communication with each SM processor. 

Each MSGS peripheral controller is designed around a microprocessor 
chip that is operated at an 8-MHz clock rate. The design’s memory 
system supports 128K bytes of dynamic RAM for software text and 
data. An additional 16K bytes of ROM is provided for initialization 
programs. In addition, 8K bytes of RAM is specifically designed for 
message queues. This special “mailbox” memory includes arbitration 
circuitry to control access in a prioritized way by the processor itself 
and the MSGS controller. 


2.2 Switching module processor 


The SM processor performs most of the call-processing functions 
that control the 5ESS switching network. The design supports up to 
16M of RAM for program text and data and up to 128K bytes of 
ROM for initialization programs. To achieve high reliability the 
processor and memory system are fully duplicated. Special circuitry is 
included to provide the required maintainability and real-time per- 
formance. 


2.2.1 Processor core functions 


The SM processor is designed around a single microprocessor chip 
that is operated at a 9-MHz clock rate. Circuitry to provide interrupt 
handling, address mapping, bus control, power-up sequencing, alarming, 
and several other special functions is included as part of the processor’s 
core design, as diagrammed in Fig. 3. 

Three interrupt levels are used in the SM processor: one for 
operational and routine maintenance, the second for reconfiguration 
messages, and the third for reset errors. There are several different 
sources of interrupts at each of these levels. They may all be masked 
under software control with the exception that critical maintenance 


HARDWARE DESIGN 1421 





TIME- 
MULTIPLEXED 
SWITCH 








DUAL-LINK 
INTERFACE 






PERIPHERAL 
INTERFACE— —— SWITCHING MODULE 
DATA BUS PROCESSOR MAIN 














CORE FUNCTIONS 


MICROPROCESSOR 
SUBUNIT BUS 
TIME-SLOT CONTROL SIGNAL 
INTERCHANGER INTERFACE PROCESSOR 


Fig. 3—Switching module processor connectivity. 






MEMORY 
SYSTEM 








messages, such as reset, sanity-timer time-out, and test system inter- 
rupts, may not be masked. 


2.2.2 Processor I/O 


I/O operations for the SM processor consist of either interprocessor 
message transmissions or communication with the other circuitry in 
the SM, such as the TSI. 

Interprocessor messages are formatted and queued for transmission 
by software routines. The SM processor transfers these messages by 
direct memory access circuitry to a synchronous data link control chip 
that applies BX.25 protocol to the messages. The messages are then 
transmitted in the appropriate control time slot by the dual-link 
interface circuit. 

Large quantities of data and program text may be loaded into the 
SM processor’s memory system. This operation, known as “pump,” 
requires special circuitry in the SM processor and a connection to the 
Peripheral Interface Data Bus (PIDB). 

The SM processor communicates with other units within the SM 
on the subunit bus. The subunit bus allows 16 bits of data and 6 
device address bits to be transmitted to the subunits. Each unit on 
this bus receives its own unit-select signal and is capable of specifying 
the number of processor wait states needed to complete its operation. 
There are currently three different subunits: the TSI, the SP, and the 
control interface. 

Of particular importance, the control interface circuitry provides an 
interface for control information to all the SM peripheral units. This 
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interface is over a standardized bus known as the Peripheral Interface 
Control Bus (PICB). By using this bus peripheral units can evolve 
independently of the SM processor. 

In addition to interprocessor messages and subunit I/O operations, 
numerous (about 100) special-function and status-register operations 
are performed. These operations, as with the message and subunit bus 
functions, are memory-mapped operations. One class of special registers 
is known as the shadow registers. These registers capture the state of 
various bus levels and other machine registers when certain maintenance 
interrupts occur. The captured information allows for higher resolution 
of the source of the interrupt that may have been caused by either a 
hardware or software failure. 


2.2.3 Processor main memory system 


The SM processor’s I/O total address spectrum encompasses 16 
million locations. Memory-mapped I/O uses 8K addresses, leaving the 
remaining locations available for program text and data. The main 
memory system provides up to 128K bytes of ROM for processor 
initialization programs, and 8K bytes of fast static RAM for operating 
system stacks and special diagnostic functions. The remainder of the 
memory spectrum may be populated with dynamic RAM as needed. 
Currently, about 4 megabytes of RAM are required, 64K bytes of 
ROM, and 8K bytes of fast static RAM. 

The dynamic RAM portion of the memory system uses memory 
planes that are organized as 40-bit words by 256K locations. The 40 
bits per location are addressable by the memory system’s controller as 
4 bytes. The remaining 8 bits contain the Hamming function code for 
that location. 

The memory system controller includes Hamming function circuitry. 
This circuitry is capable of detecting double-bit errors and correcting 
single-bit errors. This circuitry is implemented in custom gate arrays. 

The memory system includes both write-protection and stack- 
protection circuitry. The write-protection circuitry inhibits mutilation 
of software text and protected data. The stack-protection circuitry 
inhibits a software function from writing into another function’s stack 
frame and guards against stack overflows. 


Hil. SWITCHING NETWORK 


The network of the 5ESS switch, a time-space-time network, is 
depicted in Fig. 4. The time-division portion consists of distributed, 
concentrating TSIs that each multiplex up to 1024 time slots from the 
network’s periphery (lines, trunks, and service circuits) to 512 time 
slots toward the space-division portion. The CM contains a TMS that 
is a very fast space-division switching fabric that makes and tears 
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Fig. 4—Time-space-time digital switching network. 


down connections between TSIs on an individual time-slot basis. The 
TSIs and the TMS are interconnected by optical-fiber links. Timing 
for the 5ESS switch is provided by the CM’s network clock and is 
distributed by the TMS to the TSIs over the optical-fiber links. 
Within the 5ESS switch the signaling and control information is 
carried along with data throughout the switch. The TSIs, the TMS, 
and the optical-fiber links are designed for 16-bit time slots in which 
8 bits are data and 8 bits are signaling and control information. The 
signaling bits are used in a variety of ways. For example, one signaling 
bit typically carries on-hook/off-hook status and therefore can be used 
to detect switchhook “flashes.” Another signaling bit is used within 
the 5ESS switching fabric to mark the status of each time slot as idle 
or busy. Yet another bit, the parity bit, is important to the detection 
of hardware faults. Some signaling is contained within the data band, 
for example, tone-dialing signals and dial tone. The above examples 
are intended to convey the idea that a considerable amount and variety 
of signal processing must occur within the switch. Signal processing is 
performed in either of two units: an SP that is closely associated with 
each TSI and is used for functions that must be performed on a per- 
time-slot basis; and a digital service unit that performs more complex 
signal processing that can be shared over several active time slots. 


3.1 Design considerations 


Although implementation cost is a design consideration, an even 
more important consideration for the switching network hardware is 
reliability. Several of the approaches taken to ensure operational 
reliability for the switching network are listed below. 

1. All the major switching units are duplicated, and selected units 
are cross coupled. 


1424 TECHNICAL JOURNAL, JULY-AUGUST 1985 


2. Circuitry that can detect, contain, and report hardware faults is 
included. In this circuitry, error containment is a major consideration 
that must be provided so that hardware errors propagate as little as 
possible and never to the duplicated portion of the network. 

3. Although software can completely control the hardware configu- 
ration, certain classes of serious faults are handled autonomously by 
the hardware. 

Another major design consideration is to provide for potential design 
evolution. For the lifetime of the switching network to extend over 
decades or more, it is essential for the hardware design to be capable 
of evolving to take advantage of technology evolution and market 
needs. This consideration led to careful partitioning of functions with 
attention to interfaces. The following examples are illustrative. 

1. The optical-fiber links that connect the TMS to the TSIs carry 
all interconnection information (data, control, and timing). With 
technology evolution it is expected that the maximum distance possible 
for the optical-fiber link connection will be many miles. This will 
result in a widely distributed switching network. 

2. The connection of the TSI to the SM peripheral units that 
interface to lines and trunks is over a standardized data bus known as 
the PIDB. This bus carries timing, data, and signaling. Peripheral 
units can evolve independently of the TSI by using this bus. 

3. Evolution was also considered in the design of the interfaces to 
the software system. For example, the TMS controller was designed 
so that software can communicate with it via high-level messages that 
are independent of a particular hardware implementation of the TMS. 


3.2 Design descriptions 
3.2.1 Optical-fiber links 


Multimode optical-fiber links interconnect the TSIs and the TMS. 
Information is transmitted in nonreturn-to-zero format at 32.768 
Mb/s framed into two hundred fifty-six 16-bit time slots at an 8-kHz 
frame rate. Separate fibers are used for each direction of data flow. 
Therefore, four links are required in each direction to support each 
TSI. An LED serves as the optical transmitter and a pin photodiode 
is used as a light transducer in the receiver. Clock and frame timing 
is extracted from the data stream by the receiver-associated circuits 
to accomplish synchronous data transmission. Up to a full frame of 
buffer storage is provided at the receiving end to remove any constraint 
on cable-length matching. 


3.2.2 Time-multiplexed switch 


A simplex TMS is composed of two independent switching fabrics 
and a common microprocessor controller. Each 32 X 32 switch unit 
interfaces to one NCT link from as many as 30 SMs, a test input, and 
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a link from the MSGS. Optical-fiber links carrying even-numbered 
time slots connect to the “even” switch unit, while odd-numbered time 
slots connect to the “odd” switch unit. Data from the link interfaces 
are divided into dual 16-Mb/s data streams for transmission through 
the switch multiplexers. Error reporting and analysis, path request 
handling, and initialization are tasks of TMS controller firmware, 
which provides an intelligent interface between the AM and the switch 
unit hardware. Link time slots passing through faulty circuitry will 
have their busy/idle status bits forced to the idle state for interpretation 
by special maintenance circuits in the TSI. 


3.2.3 Time-slot interchanger 


Within each SM, dual 512 X 512 TSIs perform the switching 
function in each direction of the path connection (periphery-to- 
network or network-to-periphery). Special loopback paths within each 
TSI establish peripheral-to-peripheral and network-to-network con- 
nections. Each slide of the duplicated TSI is able to select automatically 
network data from either side of the duplicated TMS by examining 
“valid data” markers on every incoming network time slot. 

The digital service unit tone generators and decoders have switched 
access so that the unit can be the source of or receive data on any 
peripheral or network time slot. The SM processor also has switched 
access, which allows it to be the source of and to observe data on any 
TSI time slot. 

A 2:1 concentration function allows up to 32 peripheral data buses 
of 32 time slots each to access the 512 time slots of the TSI. 

Data going from the TSI to the periphery can be optionally 
attenuated by a digital attenuation function in the TSI. This function 
is individually controllable on a per-time-slot basis to provide a 
selectable attenuation level of up to 15 dB. 

The TSI also provides dedicated signaling bit access to and from 
the SP for all signaling and control bits on each of the 512 peripheral 
time slots in the TSI. 


3.2.4 Signal processor 


The SP can be the source of signaling and control bits on each of 
the 512 peripheral time slots in the TSI. In addition, the SP monitors 
all incoming signaling and control bits from the 512 time slots for 
state changes and reports all transitions that last longer than 6 ms. 
The SP is controlled by the SM processor so that reports of signaling 
changes on any time slot can be inhibited or allowed. 


3.2.5 Digital service unit 


The DSU provides the 5ESS switch with digital signal processing 
capabilities. The capacity of a DSU is engineered to meet peak service 
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demands so that the digital processing resources can be shared across 
all active channels. The 5ESS switch requires two applications of the 
DSU. The first application, known as the local DSU, provides heavily 
used services by locating a DSU within each SM. A local DSU is 
responsible for creating and transmitting call-progress tones, multifre- 
quency signals, tone-dialing signals, and common channel interoffice 
signaling continuity check tones. It also does dial-pulse collection, 
tone-dialing decoding, and detection of multifrequency signals. The 
second DSU application, called the global DSU, provides low-runner 
services such as three-party conferencing and special transmission test 
functions. A global DSU is shared across all SMs in an office. 

To provide reliable operation the DSU is composed of two service 
groups that share the load so that a single fault can at most reduce 
DSU capacity by 50 percent. The DSU uses AT&T Technologies 
digital signal processing chips for almost all its required services. 


IV. SUBSCRIBER INTERFACE AND METALLIC TESTING 


4.1 Line unit 


The 5ESS switch Line Unit (LU) interfaces to analog subscriber 
lines. In particular, this includes conventional loop-start, ground-start, 
and PBX trunks. Since these analog terminations typically constitute 
most of the terminations in an office, the LUs represent a large 
fraction of the total equipment and cost of the 5ESS switch. Thus, an 
important engineering consideration in the design of the LU is its 
manufacturing and maintenance cost. 

Since the LU interfaces with conventional subscriber loops, it must 
be capable of withstanding lightning surges and power crosses, and it 
must interface with a large variety of station equipment. In addition, 
it is desirable to minimize the amount of engineering required for any 
given LU within an office, since equipment terminations and traffic 
patterns tend to change and evolve with changing communication 
needs in an area. 

Finally, the reliability and maintenance of the unit are prime 
considerations in the design. It is essential that the unit require 
minimal maintenance, and it is also highly desirable that the equipment 
be designed such that faults and problems can be isolated without 
denying service to the connected subscribers. 

These design objectives are provided in the 5ESS switch LU by 
joining a new high-voltage silicon technology (used to achieve a 
concentrating network function on ceramic hybrids) with state of the 
art low-voltage complementary metal-oxide semiconductor silicon tech- 
nology (used to provide the analog-to-digital conversion function). 
This combination of technologies gives the advantages of low cost and 
digital device technology for the 5ESS switch LU. 
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Fig. 5—Subscriber line unit. 


4.1.1 Concentration network 


Subscriber appearances terminating on the LU are switched to 
channel circuits that provide battery feed, analog-to-digital conversion, 
and other functions, as indicated in Fig. 5. The concentration ratio of 
lines to channel circuits is a function of the expected traffic level in 
the application. Ratios of 8:1 and 6:1 are achieved by simply removing 
optional plug-in circuit packs. Ringing and loop-testing functions are 
provided through an access network that further concentrates the 64 
links to six high-level service circuits and two test ports. 

The fundamental building block of this space-division concentrator 
is the GDX device. This 590V silicon technology device was initially 
developed to meet the needs of the 5ESS LU application. The device 
itself is configured as a 2 X 2 switch that serves both the tip and ring 
conductors of a connection. 

The GDX device is packaged in a hermetically sealed chip carrier 
that, in turn, is mounted on a ceramic substrate that interconnects 
several GDX devices. This hybrid integrated circuit also has control 
circuitry for the local GDX devices. Since large voltages can be present 
on the tip and ring conductors (+265V), special hybrid integrated- 
circuit technology and high-voltage control circuits were also specially 
developed for this application. Five hybrid integrated-circuit codes 
were developed for the space-division concentrator network. 

These GDX hybrid integrated circuits are placed on conventional 
double-sided printed wiring boards along with the power supplies, 
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alarm circuits, overvoltage protection circuits, and the required control 
logic. Sixty-four customers are served by three circuit packs that 
constitute a grid. For maintenance and control purposes, the three 
circuit packs are handled by software as a single unit. 

The origination detection circuits do not use the usual “balanced” 
detector design, but, rather, they use a detector/filter combination on 
the ring conductor only. This arrangement with separate cutoff cross- 
point control on the 1400-ohm scan resistors to ground and battery 
allows the same electrical circuit to work for loop-start or ground-start 
applications. This option can be selected in system software and 
requires no special equipment rearrangements. 

An LU can be equipped with six to eight grids, depending on the 
expected traffic level. When equipped with eight grids, the unit serves 
512 lines with traffic levels up to 3.2 CCS/line. When equipped with 
six grids, the unit serves 384 lines with up to 5.2 CCS/line. 


4.1.2 Access network 


The space-division network as depicted in Fig. 5 provides switched 
paths between two classes of service circuits. Sixty-four channel 
circuits provide battery feed, two-wire to four-wire conversion, loop 
supervision, and analog-to-digital functions for the subscriber termi- 
nations. The access network connects high-level service circuits that 
provide ringing voltages, coin control pulses, and network test functions. 


4.1.3 Channel circuits 


Since the channel circuits serve the connected subscribers through 
a GDX network, several new requirements are placed on them. The 
GDX device exhibits a nonlinear characteristic when the current 
through the device reverses direction. To prevent this device charac- 
teristic from interfering with telephone calls in the talking state, the 
battery-feed current is supplied differentially to the tip and ring 
conductors but floating with respect to earth ground. To prevent loop 
conductors from corroding as a result of positive potentials on the 
conductors, a special circuit on the channel pack detects cable corrosion 
conditions and biases the loop conductors negative. The GDX network 
also has a finite series resistance for which the channel circuit must 
compensate with added gain. Finally, the channel circuit’s hybrid 
circuits must appropriately terminate both loaded and nonloaded 
customer loops. The appropriate balance network is selected by system 
software from information stored in the SM processor’s memory 
resulting from on-hook loop tests done periodically by system mainte- 
nance software. 

Since the 5ESS system is intended for international as well as 
domestic applications, several different versions of channel circuits are 
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available. Termination impedances, battery-feed-current profiles, and 
A-law or p-law codec versions are available. The modularity of parti- 
tioning in the system allows this critical function to take advantage of 
rapidly changing technology in planned product evolution for future 
applications. 


4.1.4 High-level service circuits 


-The subscriber loop plant requires a variety of signal voltages, 
including 20 Hz, 88V rms ringing, +130V coin-control pulses, and 
others. In addition, the LU itself must check its operations and be 
capable of further diagnostic tests that detect faulty circuits. Previous 
systems have met these requirements by terminating a variety of 
special-purpose circuits on the switching network. These special- 
purpose circuits in general were engineered for each application. 

In the 5ESS LU, special signaling requirements are met by a 
universal high-level service circuit that is configured under software 
control. Because each circuit can handle a variety of tasks and the 
holding time for a particular task is short, six circuits can meet 
the needs of 512 lines independent of the particular service mix on 
that unit. 

The high-level service circuit itself is a de-to-de converter capable 
of 15W and 200V. The output of this converter is fed to the switching 
network through a full-wave bridge-type switching circuit that acts as 
an amplifier to low-level signals produced by the signal generator on 
the circuit pack. The low-level signal generator produces 20-Hz signals 
and other required signal voltages, and the bridge switch amplifier 
produces at the high-level service circuit output a signal amplified 50 
times. This circuit pack also contains an accurate current-sensing 
circuit that is used to verify proper operation of the LU and to de- 
tect the presence of the ring trip condition during ringing on the sub- 
scriber loop. 

High-level service circuits are time shared among various system 
processes under software control. The circuit can be reconfigured 
quickly (100 ms) to provide a burst of ringing, do a power-cross check, 
collect a coin from a coin phone, or do a network integrity check. 


4.2 Metallic service unit 


The MSU provides a two-wire metallic switching matrix that 
interconnects dc and low-frequency test equipment to subscriber lines 
and metallic trunks. It is a highly concentrated resource that accom- 
modates service circuits that are traffic engineered for each office. The 
service circuits do basic test, test interconnection, and alarm-reporting 
functions. The service circuit functions have been packaged into five 
circuit pack codes that provide metallic access, GDX compensation, 
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automatic line insulation testing, and general scan and distribute 
functions. To perform a typical test the system software configures 
the service circuits into the switching network as appropriate. 

For reliability purposes, an MSU contains two service groups, each 
with its own common control circuit and interface to the SM processor. 
In large offices several MSUs may be needed to accommodate all the 
necessary service circuits. These units are interconnected by a metallic 
test interconnect bus that enables any single test resource to access 
any line or trunk in the office. 


V. TRANSMISSION INTERFACES 


There are three different transmission interface units that may 
be provided in an SM for connection to analog trunk facilities, a 
T1-carrier, and subscriber line carrier equipment. These units make 
extensive use of custom Very-Large-Scale Integration (VLSI) devices 
to achieve cost-effectiveness and dense packaging. 


5.1 Trunk unit 


The trunk unit provides the interface for all analog trunks on the 
5ESS switch. This includes both metallic and analog carrier trunks. 
The trunk types provided include E&M (both two-wire and four- 
wire), loop (both incoming and outgoing), and a test trunk interface. 

Although many types of trunks are supported, the trunk circuits 
differ only in the type of signaling and transmission scheme that they 
use. These differences are provided by trunk facility interface circuitry. 
The control and voice interface is common on all 5ESS switch trunk 
circuits and provides the analog-to-digital conversion (codec) function 
and trunk circuit control functions. 


5.2 Digital line trunk unit 


The Digital Line Trunk Unit (DLTU) is designed to interface digital 
trunks on the 5ESS switch. The primary function of the DLTU is to 
convert the bipolar T1-carrier format into a unipolar format and 
distribute the Tl-carrier frame onto the 32-time-slot PIDB frame of 
the SM. 

The DLTU contains up to ten Digital Facility Interface (DFI) 
circuits, a power-start circuit, and an equalizer circuit. The power- 
start circuit controls power to a DLTU, and the equalizer is used to 
guarantee that the DSX-1 is at an equal-level point in the office. 

The key circuit in the DLTU is the DFI circuit that provides all 
the functions required to terminate a T1 line. Four custom VLSI 
devices provide the functions of bipolar-to-unipolar conversion, framing, 
slip control, signaling extraction, and insertion and line formatting. 
The 24 PCM time slots from the T1 line are evenly distributed over 
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the 32 time slots available on the PIDB. Idle code is used to fill the 
eight remaining time slots. 

Control information from the SM is interfaced by two custom VLSI 
devices to a microcomputer. These devices provide the protocol con- 
version needed and a buffered communication interface to the SM 
processor. The microcomputer guarantees the integrity of the messages 
passed between it and the SM processor. The microcomputer also 
maintains the facility. For example, it estimates error rates, performs 
facility alarm processing, and measures the quality of the other 
circuitry in the DLTU by running in-service tests. 

A second type of DFI circuit uses an additional VLSI device and 
additional memory to provide a 4-kb/s BX.25 data link. This type of 
DFI circuit is used to interface between a Host Switching Module 
(HSM) and a Remote Switching Module (RSM) (see Section VI). It 
uses the extended. framing format in a mode that provides 23 clear 
channels for PCM and a 24th channel that carries network signaling 
information. 

Recognizing that the 5ESS switch plays an important role in the 
emerging integrated services digital network and taking advantage of 
firmware control and VLSI technology, two new capabilities not found 
in the existing network were added to the DFI circuit. They are 
64-kb/s clear-channel capability and compatibility with the new ex- 
tended framing format. Consequently, as the integrated services digital 
network evolves, the 5ESS switch can evolve without changing its 
digital interface hardware. 

For international applications a 30-channel DFI circuit is provided 
by using the same VLSI devices used on the interface for digital 
message trunks with modified firmware and front-end circuitry. 


5.3 Digital carrier line unit 


The Digital Carrier Line Unit (DCLU) provides direct interfaces for 
up to six SLC® 96 or SLC 5 carrier remote terminals. Except for 
control and data multiplex functions, it is similar to a DLTU. 

Up to 9:1 digital concentration is provided by terminating 576 lines 
through SLC carrier remote terminals spread over two service groups 
on up to four PIDBs. Each service group under normal operation will 
interface 288 lines. If a service group fails, the nonfaulted service 
group can share the load of the faulted service group, thus maintaining 
customer access to the switch. Consequently, the DCLU operates in 
an active/active shared mode. Digital concentration is provided by a 
data multiplex circuit, while distribution of control information from 
PICBs is done by a control multiplex circuit. 

To mitigate the blocking that could occur from digital concentration, 
a TSI function and on-hook/off-hook supervision are included in the 
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DCLU. A VLSI device is used for TSI and signaling functions to 
prevent severe blocking. 


VI. REMOTE SWITCHING MODULE 


The objective of the 5ESS switch RSM is to provide the capability 
within the 5ESS switch architecture to connect a remotely located 
SM over T-carrier transmission facilities to a host 5ESS switch. This 
capability enables 5ESS switches to be geographically extended from 
the host switching machine. 


6.1 Design considerations 


The applications for RSMs include the replacement of small com- 
munity dial offices and large clusters of digital loop carrier systems. 
These applications place certain implementation constraints on both 
the design and its cost. Some of the principal considerations of the 
design of the RSM are as follows: 

1. The RSM hardware design is constrained to share as much 
hardware from the SM as possible to maximize commonality and 
minimize overall hardware cost. 

2. Reliability is a major consideration that requires duplication of 
all major switching units and adherence to all the reliability constraints 
placed on a nonremoted SM. In particular, the RSM, during a loss of 
T-carrier facilities, must operate in a stand-alone mode. 

3. The RSM is designed to accommodate both domestic and inter- 
national applications. 


6.2 Design descriptions 


The remote switching capability consists of an RSM connected over 
T-carrier facilities to an HSM. As depicted in Fig. 6, the HSM is 
located in the host office with the CM and AM. Each HSM can 
support up to a maximum of five RSMs. The RSM can be located as 
far as 100 miles away from the HSM. 


6.2.1 Host switching module 


Digital facilities from an RSM are terminated on a DLTU located 
in the HSM. The termination of these digital facilities is treated by 
the HSM in the same way as any other nonconcentrated facility. The 
HSM provides access to the TMS for the data channels on these 
facilities. Each RSM requires from 4 to 20 T1 lines. An RSM used for 
community dial office consolidation is expected to require only 6 T1 
lines. Since an HSM can support traffic associated with at least 20 T1 
lines, the HSM’s excess capacity can be shared over several RSMs, 
T1 trunks, digital loop carrier systems, or analog facilities. 
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Fig. 6—Host switch with remote switching modules. 


Control links for an RSM are routed through the HSM as nailed- 
up data channels that are assigned cooperatively by the AM and the 
HSM software. The two required control links are established on the 
active side of the TMS and duplicated on the standby side. They 
appear on separate facilities between the HSM and the RSM to 
minimize the probability of a single failure taking out both con- 
trol links. 


6.2.2 Remote switching module 


An RSM is equipped in a way similar to a 5ESS SM except for the 
addition of a Facilities Interface Unit (FIU). The FIU connects the 
RSM’s SM processor and time-slot interchange unit to the digital 
trunk facilities provided by the HSM. Data, control, and timing are 
recovered from the T1 lines, and this information is reformatted into 
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a pair of NCT link signals, which are routed to the time-slot interchange 
unit over optical-fiber links. The subunits of the FIU are controlled 
by peripheral control channels from the active SM processor. Each 
peripheral control channel is realized through a PICB. A maximum of 
22 peripheral control channels are required to support up to 20 DFI 
circuits and the duplex FIU hardware. Through the peripheral control 
channels, RSM maintenance software initializes each subunit, receives 
reports of hardware failures, and does diagnostic testing. 

The FIU interface with the trunk facility is through one or two 
DLTUs that are equipped with DFI circuits. Each T1 line must be 
terminated on an office repeater that supplies signal equalization, 
regeneration, and, if needed, line powering. The resultant signals are 
routed to a DLTU through a standard DSX-1 cross-connect that 
provides test access to the facility. The DFIs are configured to operate 
in the RSM mode, whereby they provide 23 clear data channels. In 
this mode the DFIs also provide T-carrier clock signals to the FIU. 
These signals are used to lock a local crystal oscillator within the FIU 
to the network clock provided by the HSM. This oscillator, in turn, 
determines the data rate on the NCT links, thus assuring synchroni- 
zation of the RSM to its HSM. This same oscillator provides accurate 
timing for the RSM during stand-alone operation. 

Data through the FIU are multiplexed from up to 20 DFI subunits 
into two 256 time-slot frames that are formatted into two service 
groups of two NCT links. Data are similarly demultiplexed in the 
reverse direction. This multiplex/demultiplex function is performed 
under a fixed address and time-slot mapping scheme that is driven by 
time-slot clock and frame synchronization signals produced by the 
FIU control circuitry. 

The hardware of an RSM includes a standard SM with its peripheral 
circuits, an FIU, and associated DFI(s) for interfacing to the T-carrier 
facilities. The FIU itself contains only two different circuit pack codes 
and takes advantage of commonality with other 5ESS switch equipment 
by using some of the NCT circuits. 

As a result of the flexibility built into the FIU, certain expansion 
capabilities may be attained through little effort. For example, the 
RSM hardware can be configured for international applications by 
simply altering the ROM information stored in the FIU. 


VII. SUMMARY 


The 5ESS digital switching system is highly reliable, modular, 
compact, and low in cost. Its architecture will permit rapid deployment 
of new services. The modular hardware design allows switching capacity, 
processing power, and peripheral units to be added incrementally. In 
addition, this hardware modularity allows the 5ESS switch hardware 
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units to evolve independently and take maximum advantage of the 
advances in semiconductor technology. 
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The reliability, availability, and versatility of the 5ESS™ switch are highly 
dependent on the physical design of the hardware. We present a comprehensive 
description of the system and equipment designs, with particular emphasis on 
the advanced interconnection technology used, such as the fine-line, multilayer, 
printed wiring boards; ceramic substrates for functional modules; and high- 
performance, device-level packaging. The system design features described 
include new cabinet and office arrangements, the use of Fastech™ equipment, 
and new power and alarm systems. The office layout is flexible to allow growth 
in any size installation, and the modular architecture of the 5ESS switch 
makes it easy to install. We also present various testing and installation 
methods and summarize the physical design requirements and objectives for 
all equipment in the 5ESS system. 


Il. INTRODUCTION 


The 5ESS switch physical design emphasizes a wide range of system 
sizes, high packaging density, modular architecture, and advanced 
interconnection technology. The system design features minimum 
office interconnect and a variety of shipping modes, including block 
unitization, hot slide, and full unitization. Substantial floor-space 
reductions occur over predecessor analog switching systems. Equipment 
designs emphasize ease of engineering and growth, simplified human 
engineering, and distributed power conversion. Standardization of 
apparatus design is a keystone to a highly manufacturable design. In 
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addition, advances in the interconnection technologies of hybrid inte- 
grated circuit, fiber optics, and printed wiring board have resulted in 
a highly reliable, small-size-equipment realization. The high standards 
of reliable field performance have been assured through the distributed 
nature of the architecture and the use of redundancy where needed. 
Sparing costs have been minimized through application of reliability 
data to sparing calculations. The physical design, when taken with the 
flexible architecture, maintenance system design, and circuit design, 
offers a digital switch that is compact, easy to engineer and enlarge, 
highly maintainable, and reliable. 


Il. SESS SWITCH INTERCONNECTION TECHNOLOGY 


The 5ESS switch achieves low cost, high reliability, and high 
manufacturability by using a standardized, state-of-the-art intercon- 
nection technology coupled with forced air and convection cooling 
systems. High packaging density and optimum performance are made 
possible by fine-line, multiple-layer printed wiring boards, thin- and 
thick-film ceramic substrates for functional modules, and high-perfor- 
mance, device-level packaging. These technologies are optimally merged 
in minimum design time through the extensive use of Computer-Aided 
Design (CAD)* tools. Later sections deal with the four major levels of 
interconnection within each 5ESS switch unit design. 


2.1 Unit-level interconnection 


The 5ESS switch uses the Fastech packaging system, which provides 
a dense, high-performance, standardized interconnection technology. 
Each Fastech unit consists of one or more apparatus mountings and 
backplane printed wiring boards to support and interconnect the circuit 
packs (see Fig. 1). Each apparatus mounting contains about 20 to 22 
circuit packs, and typical 5ESS switch units use one or two apparatus 
mountings. . 

The apparatus mounting is designed to support circuit packs and 
alignment to backplane pin fields. Circuit pack location is highly 
flexible. Pack spacing in 5ESS switch units varies from three-quarters 
of an inch to one and one-half inches. The apparatus mounting is also 
designed to minimize resistance to vertical airflow, thus increasing the 
effectiveness of the forced air cooling system. 

The backplane printed wiring boards vary from two layers to six 
layers, and are interconnected by plated-through holes. All backplanes 
provide printed power and ground interconnection and some backplanes 
also provide printed signal paths. Pins are placed on a 0.125-inch grid 
and extend on both sides of the printed wiring board. On the side of 


* Acronyms and abbreviations used in the text are defined at the back of the Journal. 
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Fig. 1—Fastech hardware. 


the backplane away from the circuit packs, intraunit connections are 
made by automatically wrapped discrete wiring. Connectorized cables 
are also terminated on these pin fields to connect interunits. The cable 
connectors are guided and retained on the backplane by cable apparatus 
mountings. On the component side of the backplane, pin length is 
varied to improve the sequencing of power, ground, and signal connec- 
tions on pack insertion. Each circuit pack code is individually “keyed” 
to prevent insertion into the wrong pack location. 


2.2 Circuit-pack-level interconnection 


The system uses a single-size circuit pack, 7.67 by 13.375 inches, to 
maximize manufacturability and design uniformity. These circuit packs 
represent the smallest replaceable module within the system. Both 
double-sided and multiple-layer printed wiring board structures are 
used. The typical multiple-layer boards contain two or four signal 
layers, a single power layer, and a single ground layer. These boards 
are designed with a standard 0.100-inch grid of plated-through holes 
for interconnection and component placement. The standardized hole 
grid simplifies computer-aided design and automated assembly. Mul- 
tiple-layer printed wiring boards are used for high-density, high- 
performance applications within the switch (see Fig. 2). 
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PHYSICAL DESIGN 


The double-sided printed wiring board structure is typically used for 
high-volume circuit packs associated with line or trunk termination 
circuitry of the 5ESS switch (see Fig. 3). This structure allows a more 
flexible grid for the plated-through hole placement and results in a 
lower-cost interconnection medium. 

The circuit packs use either 200-contact or 300-contact connectors 
for interconnection to the unit backplane. These connectors provide a 
matrix of contacts designed to engage the backplane pin-field grid on 
0.125-inch centers. Contacts are of a highly reliable bifurcated and 
selectively gold-plated design to ensure design life. Because of the high 
insertion force required for the high numbers of interconnections, a 
latch is provided on the edge of the circuit pack to engage the apparatus 
mounting, thereby easing insertion. 

Circuit pack designs allow testing either through the edge connector 
or through direct contact with pads on the noncomponent side of the 
printed wiring board. In certain cases, component locations are printed 
on the printed wiring board to simplify circuit pack assembly, inspection, 
and testing. 


2.3 Functional-module-level interconnection 


To improve density, testability, and cost of certain functions, 
particularly analog trunk and analog subscriber line terminations, 
numerous functional modules are used. These modules are based on 
ceramic substrates with both thin- and thick-film interconnection 
technologies. The provision of precision resistors, controlled impedance, 
a high conductivity, and the resulting high density significantly enhance 
the performance of each of these modular functions. The 5ESS switch 
uses over 20 active and 100 passive ceramic modules. An example of 
this module is shown in Fig. 4. 

The ceramic module technology used in the 5ESS switch is designed 
to be a highly reliable package capable of withstanding the stresses 
due to high-voltage transients of an analog subscriber line (600V), and 
the stresses of the central office environment. Floating surface crossovers 
and programmable vias enhance routing density and provide the 
equivalent of two layers of interconnection on each of the sides of the 
ceramic. An extensive CAD system simplifies the layout of the module 
and evaluation of performance criteria. Silicon integrated circuits are 
either beam leaded and thermocompression bonded to the ceramic or 
placed in leadless chip carriers and reflow soldered to the ceramic. 
Edge-clip lead frames, reflow soldered to the ceramic, provide connection 
to both sides of the ceramic. 


2.4 Silicon-integrated-circuit-level interconnection 


The device-level packaging strategy was established to avoid prolif- 
eration of packages, to provide both printed wiring board and ceramic 
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Fig. 4—Typical ceramic modules. 


module compatibility, to provide a reliable interconnection medium, 
and to use an extensive postmolded plastic packaging capability. This 
strategy calls for use of the following three elements: (1) Dual In-Line 
Packages (DIPs) for devices requiring from 2 to 40 interconnections 
to printed wiring boards, (2) pin-grid arrays or surface-mounted leaded 
chip carries for devices requiring greater than 48 interconnections to 
printed wiring boards, and (3) either beam-leaded or leadless ceramic 
chip carrier packages for use on ceramic modules. Many devices in the 
5ESS system do not require hermetic seals; therefore, plastic packages 
are used. For those devices requiring hermetic seals for reliability, 
ceramic packaging is used. 


Ill. RELIABILITY 
3.1 Hardware reliability 


The 5ESS switch has been designed for a robustness and availability 
that is the industry standard. High availability is achieved, as a 
principle, early in the design phase by paying attention to hardware 
reliability requirements, and by evolving architectures that are the 
most feasible engineering solution. 


3.2 System architecture 


The architecture of the multimodule 5ESS switch is shown in Fig. 
5. The basic units of the switch are organized into four primary 
communities, the Administrative Module (AM), the Communications 
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Module (CM), and the Switching Module (SM). An important feature 
of the 5ESS switch is its modularity; a wide range of switch configu- 
rations, from the single module office to the large multimodule system, 
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can be developed with the basic building blocks of the system. Thus, 
by the graceful introduction of additional hardware, any office can 
grow from its initial size into a large system. This feature accounts for 
the high availability of this local digital switch, with each unit in the 
system having been improved with respect to function and availability. 
This section presents an overview of the long-term hardware reliability 
estimates for the system. It shows that the system reliability is well 
within the requirements for electronic switches. 


3.3 System reliability 


Hardware faults that can affect the operation of large segments of 
the system are mitigated by duplexing of subsystems. System outage, 
and, hence, the cessation of call processing, occurs with duplex 
hardware failure in the Message Switch (MSG) and the Time-Multi- 
plexed Switch (TMS) in the AM or the CM. The above two subsystems 
are the core equipment in the 5ESS switch; all intermodular commu- 
nications rely on the successful operation of these core units. 

Figure 6 is the reliability block diagram for the 5ESS switch, which 
is obtained from Fig. 5 by associating subunits that interact as a 
failure group and by identifying the cross-couplings in the system 
architecture. The SMs are shown in the last block for completeness 
only. They are not to be construed as part of the TMS reliability 
subblock. 


3.4 Interface module reliability 


The core units in the SMs are the Switching Module Processor Unit 
(SMPU), the Time-Slot Interchange Unit (TSIU), and the Local 
Digital Service Unit (LDSU). These units maintain intramodule 
communications; in combination with the Dual-Link Interface (DLI) 
and the TMS, they improve intermodule communication. The outage 
of the SM occurs on any duplex hardware failure within its core 
equipment SMPU-TSIU-LDSU. 

Other than during system outage, any SM may become isolated 
when the hardware dedicated to the SM is unavailable. Module 
isolation may occur during simplex operation of the TMS with the 
loss of the DLI, or with the loss of the core units in the SM. 


3.5 Interface units reliability 


Each Interface Unit (IU), except the Digital Line Trunk Unit 
(DLTU), has two service groups operating in the active-active load- 
sharing mode. The service of an interface unit is lost on the occurrence 
of coincident critical hardware failures of both service groups. Because 
of load sharing, the loss of a service group increases blocking or 
degradation of service. In general, noncritical hardware outages in the 
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Fig. 6—Reliability structure of 5ESS multimodule. 
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IUs affect service quality to a small community of customers. On the 
Digital Service Units (DSUs), the analog Trunk Unit (TU), and the 
DLTU, the service circuits and trunk are randomly assigned according 
to traffic loadings. The circuits that fail in these units are taken out 
of service, while surviving circuits share the load. 


IV. SYSTEM DESIGN 
4.1 Cabinets 


The system uses a newly designed four-posted cabinet to house the 
equipment units. The cabinets are 6 feet high, 2 feet 6 inches wide, 
and 1 foot 9 inches deep (see Fig. 7). Each blue and white cabinet will 
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Fig. 7—Exploded view of 6-foot cabinet. 


accommodate six 8-1/2 inch high Fastech equipment shelves. To 
maintain system integrity, forced air cooling is used, provided by a fan 
unit located at the bottom of each cabinet (not one of the six mounting 
positions). Fans are triplexed per cabinet, deliver 250 through 300 
Cubic Feet per Minute (CFM) of filtered air, which is drawn from the 
wiring aisle. An arrangement of fan flaps prevents loss of air flow if a 
fan fails. Alarms detect individual fan failures. The cabinet design also 
includes two fuse/filter units for power distribution at the top of each 
cabinet. The 6-foot design precludes the need for external earthquake 
bracing in any office location. 


4.2 Teletypewriter and telephone jack access 


Teletypewriter (TTY) and telephone jack access is provided by the 
fuse/filter units located in the message switch and Switching Module 
Control (SMC) cabinets. These access points are multiplied throughout 
the office. Access is also provided at the Master Control Center (MCC), 
at each Supplementary Trunk Line Work Station (STLWS), and at 
the distributing frame for connection to other areas of the central 
office and to remote switching modules. 
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Table |—Cabinet configurations 


Cabinet Acronym 


Switching module control SMC 


Line interface LNI 
Line trunk peripheral LTP 
Master control center MCC 
Message switch MSG 
Miscellaneous M 
Power distribution PCFD3 
Supplementary trunk STLWS 


line work station 


Time-multiplexed switch TMS 


4.3 Cabinet arrangements 


The system uses a limited number of cabinet arrangements for 


Number required 


1 per switching module 

As required 

1 to 4 per interface module 

1 per office 

2 per office 

As required 

1 to 6 per office 

1 to 6 per office initial 
TLWS provided as 
part of MCC 

2 per office 


simplicity and ease of office engineering, as shown in Table I. 


4.4 Office arrangements 
4.4.1 Floor plans 


Standard cabinet arrangements have been developed to minimize 
engineering and installation costs. A universal plan has been developed 
that permits natural, yet flexible, growth from the smallest to the 
largest installation. Other plans are also available for single module 
and remote switching module applications. Figure 8 depicts a typical 
multimodule office floor plan, and Fig. 9 shows a remote module plan. 


Some constraints on cabinet placement must be observed. 
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DPC — DISK POWER CABINET PCCA — PROCESSOR CONTROLLER CABINET 
LTP — LINE TRUNK PERIPHERAL PCFD — POWER DISTRIBUTION CABINET 

M — MISCELLANEOUS SM — SWITCHING MODULE 
MCC — MASTER CONTROL CENTER SMC — SWITCHING MODULE CONTROL 
MHD — MOVING HEAD DISK TUCA — TAPE UNIT CABINET 


MSG — MESSAGE SWITCH 


Fig. 8—Typical multimodule office floor plan. 
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A 


LTP — LINE TRUNK PERIPHERAL 

M — MISCELLANEOUS 
PCFD— POWER DISTRIBUTION CABINET 
SMC — SWITCHING MODULE CONTROL 


Fig. 9—Remote module floor plan. 


1. The SMC and Line Trunk Peripheral (LTP) cabinets comprising 
a given switching module must be arranged in a specific pattern to 
minimize intercabinet cable lengths. 

2. The message switch cabinets must be located within 50 cable feet 
of the AT&T 3B20D2 computer to maintain the integrity of the signals 
between these equipment entities. 

3. Power distribution cabinets are to be placed in line with one 
another and should be centrally located with respect to the cabinets 
they serve. 

4. To minimize cable congestion, the distributing frames should 
grow perpendicular to cabinet lineups; however, other layouts can be 
accommodated. 

5. The system floor plans have been designed to fit the New 
Equipment-Building System (NEBS) building bay standards. The 
system’s modular design makes it readily adaptable to existing buildings. 


4.4.2 Cable rack, end guards, and office lighting 


The system uses a newly designed overhead cable rack system. 
Cabinet-supported cable racks, 10 inches high and 21 inches deep, are 
positioned in 90- and 30-inch increments. Unlike previous systems, it 
has only two cable compartments, one of which provides separation 
and mechanical protection for the fiber optics, while the other contains 
all other intercabinet cables. Interlineup connection uses telescoping 
cross-aisle cable racks to simplify engineering and installation. 

There are end guards at the ends of each cabinet lineup and at each 
exposed cabinet position within the lineup. Aisle directories naming 
the cabinets in each lineup, and lighting control switches are on the 
ends of lineup end guards. 

The cabinet-supported cable rack is also arranged to support the 
via cable rack system and an optional overhead lighting system. 


4.4.3 Distributing frames 


4.4.3.1 Conventional or open type. The Low-Profile Conventional 
Distributing Frame (LPCDF) or similar conventional mainframes may 
be used with the 5ESS switch, particularly in office sizes up to 6000 
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Table II—Cosmic I! mainframe 
arrangements 


Termination Field (Pairs) 


COSMIC II Type Facility Equipment 
Mini 6,000 7,600 
Combined 30,000 48,000 
Subscriber 100,000 100,000 
Trunk 30,000 36,600 


lines. This conventional-type distributing frame meets the needs of 
the NEBS standards and is a floor-supported, earthquake-resistant, 
low-profile version of the early distributing frames. Standard equipment 
arrangements are available to minimize jumper congestion. 

4.4.3.2 COSMIC II. The COSMIC II distributing frame is a modular 
mainframe that can meet the wide range of office configurations. 
Depending on the best planned office size in terms of total terminations, 
one of the arrangements shown in Table II can be used. 


4.4.4 Protection 


The first stage of protection is provided by a new distributing- 
frame-mounted gas tube protector. Most newer connectors will accept 
the plug-in unit, although older connectors, such as the C50 and 300 
type, will not. 

For single-entity wire centers, all exchange cable pairs should be 
terminated on Distributing Frame (DF) connectors that accept the 
new protectors. Some retrofitting may be required in existing wire 
centers that reuse older DFs. A secondary strategy is used in multientity 
wire centers where retrofitting costs could be prohibitive. In these 
applications, two options exist: | 

1. Use of a newly designed horizontal mainframe connecting block, 
which provides gas tube protection as well as equipment termination 
and jumper access. 

2. Placement of the Line Interface (LNI) cabinet between the 
mainframe and the equipment cabinets. The LNI cabinets may be 
installed in the equipment lineups or may be placed in a separate area 
to meet local requirements. Each LNI cabinet provides protection for 
2048 pairs at an 8:1 Line Concentration Ratio (LCR). 


4.5 Office alarms 


Office alarm equipment reports hardware conditions such as fuse 
operation, voltage and current levels, and software triggers such as 
diagnostic failures. Such alarm conditions are reported by the system 
to the MCC, where a video display identifies the exact location of the 
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reported trouble. The alerting function of the office alarm plan is 
provided by an audible and visual alarm system. Distinctive audible 
devices alert the user to the trouble, indicating the particular level of 
importance. Visual indicators may also be provided at switch room 
exits. The traditional aisle pilot lamps are not provided, to ensure that 
the user begins the search for the trouble location by using information 
at the MCC and not by following visual indicators. 


4.6 Power 
4.6.1 Overview 


The 5ESS switch requires only —48V power from a dc power plant. 
The individual voltages required by each circuit are provided by dc-dc 
power converters equipped in each unit or by on-board power converters. 
Ringing and tone voltages are provided within each switching module. 
Common system equipment requiring other than —48V or ring and 
tone voltages must be supplied via bulk converters or separate plants 
provided by the customer. 


4.6.2 Power plants 


The power plant used with the system is a —48V plant with a 
voltage range at the power distribution cabinet of —42.75 to —52.5V. 
The —48V power may be obtained from any modern power plant with 
the required voltage range, including the 111A, 151B or C, 153A or 
155A plants, or the new Lineage™ 2000 plant. Power plants can be 
operated in parallel to supply power for large offices. 

Existing power plants using Counter-Electromotive Force (CEMF) 
or end-cell switching (one or two cells) may be used, as long as they 
do not violate the system grounding constraints. Older plants incor- 
porating SCR-type rectification will require additional protection to 
prevent damage to the 5ESS switch from lightning or power transients. 


4.6.3 Battery reserve plant 


A battery reserve plant is required to continue service during outages 
of commercial power and to provide proper filtering for the power 
plant. Typically, there is a three-hour reserve for attended offices, and 
an eight-hour reserve for unattended offices. This plant should be 
designed to meet local job conditions using parallel strings of rectangular 
or round cells. 


4.6.4 Standby power 


A standby alternator can operate the central office if a prolonged 
commercial power outage occurs. For small offices, a receptacle may 
be provided to connect a portable ac generator, whereas a stationary 
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engine should be used in larger offices. Local conditions will dictate 
the configuration of this reserve system. 


4.6.5 Power sharing 


In some applications it may be economically attractive to share a 
battery plant between the 5ESS switch and other central office 
equipment. The rules for power sharing are the same as those defined 
in previous electronic switching systems. Power for the non-5ESS 
- switching equipment must be supplied from a separate power distri- 
bution cabinet/frame located in the non-ESS™ switch area. Power 
feeders supplying the frame must be run via the ground window and 
have the ground side of the feeders bonded to the single-point ground. 
All shielded cables running between the two areas must have their 
shields grounded at the 5ESS switch end and be isolated from the 
ground at the other end. 


4.6.6 Power distribution 


Power distributing cabinets are used to distribute the —48V power 
to the equipment cabinets. They are centrally located in the area of 
the cabinets they serve in order to minimize feeder congestion and to 
maintain the required voltage drops in the feeders. Typically, one 
power distribution cabinet is required for 36 equipment cabinets. 


4.6.7 Grounding 


The 5ESS switching equipment is connected to an isolated ground 
plane that has no contact with building ground or other foreign 
ground planes except for a single connection to the floor central office 
ground. The single-point ground system eliminates the possibility of 
transient current flow through the 5ESS switch ground plane from 
the sources outside the system. 


4.7 Office interconnection 


All connections between equipment entities in the 5ESS switch are 
fully connectorized. All signal and tip and ring leads are terminated 
on the unit backplanes using Fastech backplane connectors. Connec- 
torized mainframe blocks are used to terminate tip and ring leads from 
the line units, as well as leads from the trunk units, metallic service 
units, and the Trunk Line Work Station (TLWS). 

Control and data signals between the SMC and its peripheral units 
are completed using double-ended connector cables that run directly 
between cabinets as opposed to being run in the overhead racking 
system. Optical fibers are used to complete the highly critical connec- 
tions between the switching modules and the TMS or MSG. 

This high degree of connectorization greatly reduces the installation 
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interval, simplifies the growth procedures, and eases factory assembly 
and testing. 


4.8 Factory testing/installation 


The system is tested in the factory in segments called blocks. A 
core system, consisting of the 3B20D computer, the CM, and one or 
two SMs, is tested and shipped as a unit. Individual SMs are tested 
and shipped as separate blocks to the office site, where full system 
testing is completed by the installer. This method eliminates duplication 
of tests and minimizes the cost of factory testing. 

The system can also be installed on site in a temporary facility, 
tested, cut into service, and then moved into its final position after 
the replaced equipment has been removed from service. This method, 
known as “hot slide-in,” can be done in several ways. Figure 10 depicts 
the sequence followed in hot slide-in of an office. The entire system 
can be moved in three lineup blocks, or the core system can be moved 
independently of the switching modules. The switching modules need 
only be located within 1000 cable feet of the TMS/MSG before or 
during the hot slide-in procedure. These methods greatly simplify 
installation and add another dimension of flexibility to the 5ESS 
switch. 


V. EQUIPMENT PHYSICAL DESIGN 
5.1 Switching module 


The SM terminates lines and trunks, and converts their signals into 
the digital format of the 5ESS switch. The SM also performs much of 
the call-processing function. 

Physically, the SM consists of two to five cabinets, which may 
be configured to suit the type and quantity of lines and trunks 
the particular SM serves. A distinction is made between the 
types of cabinets that comprise the SM, the SMC, and the LTP, as de- 
scribed below. 

Equipment that is common to all SM designs is housed in the SMC. 
This common equipment consists of the SMPU, the TSIU, and the 
LDSU. The SMC cabinet equipped with these common elements is 
shown in Fig. 11. Only one SMC cabinet exists for each SM. Later 
paragraphs describe the units of the SMC. 


5.1.1 Time-slot interchange unit 


The TSIU is a two-shelf unit that provides time-slot switching, 
Network Control and Timing (NCT) link interface, signal processing, 
data interface, and control interface. The unit is fully duplicated, with 
each simplex half associated with the corresponding simplex half of 
the SMPU: The halves are referred to as side 0 and side 1, as viewed 
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Fig. 10—Hot slide-in sequence. 


from the front of the unit. At any given time, only one side is active 
and the other is in a standby mode. 

Figure 12 is a physical layout of the unit, showing the physical 
partitioning of the TSIU’s function. Note that the TSIU halves are 
mirror imaged. A brief description of these functions follows. : 

5.1.1.1 Time-slot switching. The TSIU performs the switching of 512 
time slots per 125-us frame from [Us to the TMS, and from the TMS 
to the [Us. It also can switch peripheral time slots with peripheral 
time slots (i.e., for intramodule calls), and TMS time slots with TMS 
time slots (for maintenance). This Time-Slot Interchanger (TSI) 
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Fig. 11—SMC cabinet. 


function is provided on five TN-type multilayer circuit packs in 
the unit. 

5.1.1.2 Dual-link interface. The TSIU provides an interface to the 
NCT links with its DLI circuits. The DLI extracts timing from the 
NCT links for the SM, accommodates the optical transmit and receive 
circuits required to terminate the fiber-optic NCT links, and provides 
the SMPU with a message time slot from the 256 time slots of the 
NCT links. Two DLI circuit packs are equipped in the TSIU, but are 
associated with the TMS from a reliability group standpoint. Because 
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of this relationship, each DLI is coupled to each TSIU/SMPU simplex 
half, and each DLI has its own power converter. 

5.1.1.3 Data interface. Two data interface circuit packs are equipped 
on the TSIU to provide up to 32 Peripheral Interface Data Buses 
(PIDBs) from the TSIU to the [Us of the SM. 

5.1.1.4 Control interface. The TSIU provides up to 46 Peripheral 
Interface Control Buses (PICBs), which deliver control information to 
the JUs from the SMPU. Each control interface circuit pack has 23 
control ports available. 

5.1.1.5 Signal processing. The signal processor, housed in the TSIU, 
is a three-board complex that transmits and receives address and 
supervisory signaling from the [Us. 


5.1.2 Local digital service unit 


The LDSU is a one-shelf unit located in the SMC cabinet. It is 
divided into two service groups, each of which requires 32 time slots, 
which are not a subset of the 512 TSI internal time slots. The LDSU 
provides each SM with tone decoding and tone generation functions. 
Figure 13 depicts the LDSU. Each service group has its own power 
conversion and common circuit, and is then equipped with tone 
generators and decoders as required. 

5.1.2.1 Tone decoding. The Universal Tone Decoder (UTD) of the 
LDSU recognizes Touch-Tone (16-tone pairs) and multifrequency (15- 
tone pairs) signals. The UTD circuit pack contains four decoders. 

5.1.2.2 Tone generation. The Universal Tone Generator (UTG) of the 
LDSU is capable of generating the following tones: 

. Audible ring 

. Dial tone 

. High tone 

Low tone 

. Call waiting 

Preemption 

. Multifrequency signals (15-tone pairs) 

. Touch-Tone signals (16-tone pairs) 

. Common Channel Interoffice Signaling (CCIS) continuity check 
tones (1780 and 2012 Hz). 

The UTG has 32 channels of tone generation per Multilayer Board 
(MLB)-type circuit packs. 


WOONHNRWONH 


5.1.3 Switching module processor unit 


The SMPU is a one-shelf unit housing the SM memory and 
microprocessor complex. The SMPU performs most of the call-pro- 
cessing and maintenance functions for the lines and trunks terminating 
on the [Us of the SM. The SMPU is fully duplicated and operates in 
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Fig. 13—Local digital service unit. 
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an active/standby mode, as described in Section 5.1.1. The active 
simplex half has total control over the entire SM, and also updates 
the standby side’s data. Figure 14 is a physical layout of the SMPU. 

5.1.3.1 Microprocessor. The SMPU is based on the microprocessor. 
The entire processor complex is accommodated on five multilayered 
circuit packs. 

5.1.3.2 Memory. Most of the SMPU program text and data are kept 
in RAM with backup on the moving head disk of the 3B20D computer. 
Five memory planes can be housed within each service group of the 
SMPU. At this writing, 1M-byte planes are used, with 2M-byte planes 
planned for the near future, allowing 5M bytes or 10M bytes for 
the SM. 

5.1.3.3 Fast pump. The SMPU also contains the fast-pump controller 
circuit, which enables the central processor to down load memory to 
both sides of the SMPU in an expeditious manner. One PIDB is used 
as a channel to provide the means for data transfer. 


5.2 Line trunk peripheral cabinet 


The LTP cabinets house all the [Us of the SM. There may be up 
to four LTPs associated with one SM, and each LTP has six unit 
positions available for equipage. LTPs equipped with IUs are shown 
in the SM configured in Fig. 15. 


5.2.1 Line unit 


The 5ESS switch line unit provides the interface to virtually all 
types of analog subscriber lines (see Fig. 16). The unit’s modular 
design allows smooth growth from termination for 256 lines at a 4:1 
concentration to termination of 512 lines at an 8:1 concentration. The 
line unit is a functionally partitioned, two-shelf unit containing up to 
50 circuit packs at the 512-line capacity. The line unit provides all 
line interface functions, including battery feed, overvoltage protection, 
ringing, supervision and scan, analog-digital encoding and decoding, 
the hybrid function, two stages of line concentration, and test access. 
Unit 5V power is derived from one fully duplicated bulk dc-dc 
converter. Control interface to the peripheral interface control bus 
and control fanout is provided by two additional fully duplicated cir- 
cuit packs. 

5.2.1.1 Concentrator. The line unit concentrator is partitioned into 
grids, each of which terminates 64 analog lines. A minimum of four 
and a maximum of eight grids may be equipped in each line unit. The 
grid is contained on three circuit packs, two of which perform over- 
voltage protection, scan functions, and the first stage of concentration 
for 32 lines each. The third circuit pack performs second-stage concen- 
tration, and provides —48 Vdc to +300 Vdc power conversion and 
control for the grid. Each 64-line grid is configured in a simplex 
arrangement, whereas all other line unit functions are fully duplicated. 
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Fig. 15—Line trunk peripheral cabinet. 


5.2.1.2 Channel. The battery feed, encoding-decoding, and hybrid 
function is provided on the channel circuit packs. Eight channel packs, 
each containing circuitry for eight individual channel circuits, are 
equipped in all line units. These packs provide 64 Pulse Code Modu- 
lation (PCM) outputs, which may be accessed by any of the 512 analog 
line terminations through the concentrator. The interface of these 
PCM channels to the peripheral interface database structure is per- 
formed on one fully duplicated circuit pack. 
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Fig. 16—Line unit. 


5.2.1.3 Ringing and test. Ringing and test functions are provided from 
the high-level service-circuit pack. A minimum of four and maximum 
of six of these high-level service circuits may be equipped in each line 
unit. The ring and test functions are connected to individual subscriber 
lines through the ring and test access network and the concentrator. 
The access network, contained on two circuit packs, is fully duplicated 
for high availability, and allows access of any of the ringing or test 
circuits to any subscriber line. 


5.2.2 Digital line trunk unit 


The DLTU of the 5ESS switch will interface with a large number 
of existing digital transmission terminals. It is a single-shelf unit that 
contains up to ten Digital Facility Interface (DFI) circuit packs, each 
of which terminates a single T1 line. These circuit packs use the MLB 
technology. 


5.2.3 Digital carrier line unit 


The Digital Carrier Line Unit (DCLU) is used to terminate T1 lines 
from integrated SLC® 96 carrier systems, where up to 96 subscribers 
without concentration at the remote terminal are provided with 96 
channels to the 5ESS switch. Mode II is the carrier-concentrator 
mode, where up to 96 subscribers share access to 48 channels to the 
5ESS switch. The DCLU is a two-shelf unit equipped with DFI, data 
multiplexers, control multiplexers, equalizers, and power units. Each 
DCLU terminates up to 30 T1 lines and consists of two service groups. 
A maximum of six SLC 96 carrier remote terminals may be terminated 
on a DCLU. These circuit packs use the MLB technology. 


5.2.4 Trunk unit 


The TU provides for the termination of high-traffic voice-frequency 
trunks. Specifically, it can terminate interoffice trunks and trunks to 
switchboards, operator positions, and announcement machines. Simplex 
equipment can terminate up to 64 trunks. A TU is a single-shelf unit 
divided into two separate service groups, each with its own power and 
common circuitry. Each service group terminates up to 32 trunks. 
Hach trunk circuit pack is double-sided and contains four trunk 
circuits. The TU provides an interface for the following multipurpose 
trunk types: 

. Loop supervision, outgoing, two-wire local 
. Loop supervision, outgoing, two-wire toll 
Loop supervision, incoming, two-wire local 
. Loop supervision, incoming, two-wire toll 
. E&M supervision, two-wire local 

. E&M supervision, two-wire toll 


Oow wn ee 


PHYSICAL DESIGN 1465 


7. E&M supervision, four-wire local 
8. E&M supervision, four-wire toll 
9. Local test desk. 


5.2.5 Modular metallic service unit 


The Modular Metallic Service Unit (MMSU) consists of a one-shelf 
basic unit and up to three additional growth units. Each shelf is split 
into two service groups, and each service group has its own power and 
common circuitry. It can also accommodate up to nine metallic service 
packs whose functions are outlined below. 

5.2.5.1 Metallic access. The MMSU provides the metallic access 
function on one circuit pack. Metallic access provides an access 
network that can interconnect analog facilities to test equipment. 

5.2.5.2 Scan and signal distribution. A scan circuit pack and a signal 
distribute pack in the MMSU monitor the power supply status and 
maintenance status of the periphery. 

5.2.5.3. Gated-diode-crosspoint compensation. The Gated-Diode-Cross- 
point (GDX) compensator pack corrects leakage during testing of 
analog lines. 

5.2.5.4 Automatic line insulation testing. One Automatic Line Insulation 
Testing (ALIT) circuit pack performs internal testing functions, such 
as insulation of all customer lines, short circuit, and foreign potential, 
and other specific tests on individual lines. 


5.2.6 Global digital service unit 


The Global Digital Service Unit (GDSU) is a one-shelf unit with 
two service groups. The unit design (i.e., backplane) is identical to the 
LDSU design, but is equipped with a different set of circuit packs, 
which perform lower-usage digital service functions. Each service group 
has its own power, common circuit, and space for up to eight service 
circuits, whose type and quantity are equipped as the needs of 
the office require. The GDSU may be shared among SMs in an 
office, being accessed by the switching network. GDSUs connect to 
the TSIU in the SM by way of PIDBs. The primary GDSU functions 
are described below. 

5.2.6.1 Universal conference circuit. The Universal Conference Circuit 
(UCC) double-sided circuit pack of the GDSU contains five three-port 
conference circuits. At this writing six-port conferencing is planned 
for 1985. 

5.2.6.2 Transmission test function. The Transmission Test Facility 
(TTF) of the GDSU performs all the voice-frequency tests required in 
the office. Four circuit pack codes provide 

1. Facility testing 

2. CODEC testing 

3. Noise, loss, and frequency response measurements 
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Fig. 17—Time-multiplexed switch cabinet. 


. 100 test line 

. 102 test line 

. 105 test line 

. Remote office test line 
. Touch-Tone test line. 


cowl Oe 


5.3 Time-multiplexed switch 


A 5ESS switch equipped with more than one SM requires a TMS. 
The TMS cabinet (see Fig. 17) provides space-division switching of 
time slots between two or more switching modules. The TMS routes 
control, data, and PCM-encoded voice between the switching modules 
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over fiber-optic links called NCT links. The equipment in a TMS 
cabinet is arranged to accommodate from 2 to 30 switching modules. 
For reliability, the TMS equipment is duplicated in a second TMS 
cabinet and operates in a duplex two-cabinet configuration. Equipment 
units within the TMS cabinets are job engineered with respect to the 
number of SMs in the office. Each TMS simplex cabinet contains two 
TMS Units (TMSUs) and one TMS Control Unit (TMCU). These 
units are provided for the minimum TMS configuration (two SM 
offices). The TMS (office) capacity can be smoothly increased to 30 
SMs by populating the TMSUs with additional circuit packs, NCT 
links, and power converters. The TMS can be expanded quickly and 
easily in the field in this manner. 


5.3.1 TMS switch unit 


The TMSU is a single-stage space switch with 32 input ports and 
32 output ports. There are two TMSUs in each simplex TMS cabinet 
separated by a TMCU. The TMSU located above the TMCU switches 
“even” time slots, and the TMSU located below the TMCU switches 
“odd” time slots. The even and odd TMSUs are connected to the TSI, 
which handles both even and odd time slots and is fully duplicated, 
by full-duplex optical-fiber data links. Each link carries even or odd 
time slots only. The exception to this even/odd arrangement is the 
link to the MSGS unit, which must carry both even and odd message 
time slots. 

A TMSU is a two-shelf unit arranged to mount a total of 4 power 
converters (2 per shelf) and 27 Fastech multilayer circuit packs. The 
power converters supply power to all the circuit packs within their 
shelf. The capacity to switch 2 to 30 SMs is determined by the 
arrangement of circuit packs, NCT links, and power converters in the 
even and odd TMSUs. 

5.3.1.1 NCT links. Fiber-optic transmitters and receivers, along with 
fiber-optic cable, make up the NCT links that are positioned on the 
backplane of the TMSU. They connect directly behind the Link 
Interface (LI) circuit packs that are housed on the equipment side of 
the backplane. Figure 18 shows a typical fiber-optic connection. 

5.3.1.2 Fanout, fabric, and link interface. TMSUs are configured with 
the clock and data fanout circuit packs in the center of each shelf. 
Located on each side of the fanout pack are the fabric circuit packs, 
and outside the fabric are the LI packs. This scheme allows for the 
shortest path switch nets and better timing control. 


5.3.2 TMS control unit 


The TMCU provides the control path setup and the craft interface 
for all units in the TMS cabinet. The TMCU is a single-shelf unit 
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containing two power converters and seven circuit packs, including 
the control and display pack. The TMCU is equipped with a full 
complement of circuit packs and power converts regardless of the 
multimodule office size. The circuit pack complement contains one of 
each of the following packs: 

. Message Link Interface (MLI) pack 

. Test pack 

. Clock interface pack 

. TMS maintenance pack 

. TMS control pack 

. TMS interface pack 

. Control and display pack. 


Aon WN Fe 


5.4 Message switch cabinet 


The MSG in the 5ESS switch provides synchronous control-data 
paths between the AM and the SMs, provides a synchronous control- 
data path for module-to-module communications, and timing to the 
rest of the 5ESS switch; it also synchronizes the switch to the 
switching network. For each simplex cabinet, the MSG contains one 
Message Switch Control Unit (MSCU), three to four Message Switch 
Peripheral Units (MSPUs), and one Message Interface Clock Unit 
(MICU). For high reliability, the MSG equipment is duplicated in a 
second MSG cabinet and operates in a duplex two-cabinet configuration. 
Equipage of the units within the MSG cabinets is job engineered with 
respect to the number of SMs in the office. Growth procedures will be 
described in the sections that follow. Figure 19 shows a message switch 
cabinet. 


5.4.1 Message switch control unit 


The MSCU is an interface between the AM and the peripheral 
controllers in the MSPU. The MSCU is a single-shelf unit that houses 
in its normal configuration one power converter, one Control and 
Display (C/D) circuit pack, and either six or seven MSCU circuit 
packs. Two additional positions have been reserved in the MSCU for 
a test circuit pack and its converter. Since the MSCU has its own 
power converter and C/D circuit pack, it can be powered down without 
affecting other units. The circuit pack complement in the MSCU 
consists of 
. One control and display 
. One duplex dual-serial bus selector 
. One bus interface controller 
. One peripheral interface controller 
Two Microcontrol Stores (MCSs) 

. One or two input/output microprocessor interfaces. 


Oo Powe 
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Fig. 19—Message switch cabinet. 


The quantity of input/output microprocessor interfaces depends on 
the office size. All these circuit packs, except the C/D and MCS, are 
MLB types. The C/D and MCS are Double-Sided Rigid (DSR) types. 


5.4.2 Message switch peripheral unit 


The MSPU is a single-shelf unit that houses the Module Message 
Processor (MMP), Foundation Peripheral Controller (FPC), and Pump 
Peripheral Controller (PPC). The MMPs handle message traffic be- 
tween the MSCU and the modules via the MICU and TMS. The FPC 
passes control data over the control and diagnostic access link from 
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the AM via the MSCU to control the configuration of the MICU, as 
well as to control the TMS. The PPC can quickly initialize the module 
memory. 

In the minimal multimodule MSG configuration, three MSPUs are 
required for a simplex MSG cabinet. Two of these units house MMPs 
and one houses the FPC and PPC. Each of the units is equipped with 
its own power converter and C/D circuit pack. Thus, one MSPU can 
be powered down without affecting other MSG hardware. 

5.4.2.1 Module message processor. Up to four MMPs can be housed 
in one MSPU. With two units fully equipped with MMPs (MMPs 
must be added simultaneously to two MSPUs per simplex MSG), the 
MSG can support 32 modules. For offices larger than 32 modules, a 
dual-community version (growth unit) of the MSPU is added to the 
cabinet. This unit contains two separate power groups (two power 
converters and two C/D circuit packs) and allows growth to 48 
modules. 

The MSG grows by adding MMP circuit packs. An MMP contains 

1. One Message Switch Peripheral Processor (MSPP) 

2. One module message processor 1 

3. One or two module message processors 2. 

These packs are added simultaneously to each of two MSPUs per 
simplex MSG for support of up to 32 modules (see Fig. 20). When an 
MMP consists of four circuit packs, it can handle one time slot for as 
many as eight modules. An MMP may also consist of three circuit 
packs. In this configuration, up to four modules can be supported. 
Thus, in summary, three MMP circuit packs are required in each of 
the two MSPU communities to support up to four modules, four packs 
are required to support up to eight modules, seven are required to 
support up to 12 modules, eight packs are required to support up to 
16 modules, etc. When MSPU communities 2 and 8 are fully equipped, 
32 modules can be supported. In a similar way, MMP circuit packs 
can be added to each community in the dual-community (growth-unit) 
version of the MSPU for growth to 48 modules. All circuit packs of 
the MMP are MLB-type packs. 

5.4.2.2 Foundation peripheral controller. Each MSG cabinet has one 
FPC, which contains one each of the MSPP or FPC codes of MLB- 
type circuit packs. 

5.4.2.3 Pump peripheral controller. Each MSG cabinet has one PPC, 
which contains one each of the MSPP or PPC codes of MLB-type 
circuit packs. 


5.4.3 Message interface clock unit 


The MICU is a single-shelf unit that houses the Message Interface 
(MI), LI, and Network Clock (NCLK). The MICU provides system 
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Fig. 20—Message switch peripheral unit. 


synchronization and the interface for transmitting message time slots 
between the module controllers via the TMS and the AM. 

5.4.3.1 Message interface. The MI consists of one each of the four 
MLB-type circuit packs listed below: 

1. Message interface 1 

2. Message interface 2 

3. Message interface 3 

4. Message interface 4. 
It multiplexes and demultiplexes the message time-slot information 
between the MMPs and the LI. 

5.4.3.2 Link interface. The LI consists of two MLB-type link interface 
circuit packs (link interface 1 and link interface 2). It provides 
the termination for the NCT link in the MICU. The LI transmits 
and receives data as 256 control time slots over the link to and from 
the TMS. 

5.4.3.3 Network clock. The NCLK comprises three circuit packs—the 
controller, the digital phase-locked loop, and the synchronizer. Two 
versions (two different circuit packs) of the synchronizer are available— 
one for use in offices that are tied to T1 lines (slaved offices), and one 
for stand-alone offices. The NCLK provides master system timing and 
synchronization for the 5ESS switch. The NCLK always contains 
three MLB-type circuit packs per MICU. 


5.5 Miscellaneous cabinet 


The miscellaneous cabinets, two of which are required for minimum 
equipage, house peripheral units that do not require module time slots 
or control ports. Each cabinet is equipped with two fuse and filter 
units but does not require fan units. The miscellaneous cabinets are 
equipped with the following units: inverter, office alarm unit, converter 
and local frame (tel jack) unit, resistor panel, 13A announcement 
system, external sanity monitor, and inductor unit. Figure 21 shows a 
maximum configuration of the two cabinets, and each unit is described 
in the paragraphs below. 


5.5.1 13A announcement system 


The 138A announcement system is a multichannel system allowing 
one to eight channels to provide recorded announcements of various 
lengths. Each channel can record and play one message. A maximum 
of four units can be mounted in one cabinet. 


5.5.2 Inductor unit 


The inductor unit provides a filter for the powering of the 138A 
announcement systems. This 4-inch by 2-foot 1-inch unit is required 
only when 13A announcement systems are used. 
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Fig. 21—Miscellaneous cabinet. 


5.5.3 Resistor panel 


The resistor panel is a 4 inch high, 23-1/4 inch wide unit that 
provides a mounting for cables and current-limiting resistor assemblies. 


5.5.4 Inverter 


The inverter unit is required to provide emergency 117V ac to the 
data-set cabinet and equipment at the master control center. This unit 
is 26-1/4 inches high, 23 inches wide, and 15 inches deep. 


5.5.5 Converter and local frame (tel jack) unit 


The converter unit is a 4-inch high, 2-foot 2-inch wide mounting 
plate equipped with a housing for a 131-type dc-to-de power converter 
that supplies the external sanity monitor. Also mounted on this unit 
is the circuitry required for interframe communications. 
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5.5.6 External sanity monitor 


The external sanity monitor provides a test of the call process that 
establishes a call between two switching modules. The equipment 
required to do this is mounted on the 

1. Dial-tone-delay alarm unit, which is 4 inches high by 25 inches 
wide; 

2. Distribute-point-applique unit, which is 2 inches high by 25 
inches wide; and the 

3. Converter and local frame (tel jack) unit, previously described. 


5.5.7 Office alarm unit 


The office alarm unit is a Fastech 8-inch-high apparatus housing 
equipped with the following functions: 

1. Office alarm circuit 

2. Scan-applique circuit 

3. Remote alarm unit 

4. Broadcast dynamic control. 


5.6 Data-set cabinet 


The data-set cabinets are used to house various operational support 
systems that interface with the 5ESS switch. These cabinets are 
equipped with shelves and various styles of apparatus mountings to 
accommodate these systems. Two cabinets are required; one cabinet 
has backup ac power (protected ac), and the other is supplied with 
conventional ac power (essential ac). 

Each 6-foot-high, 21-inch-deep, 30-inch-wide cabinet contains a 
cooling unit. The following list details by function which systems are 
in each cabinet. 


5.6.1 Protected ac cabinet 


The protected ac cabinet contains the following systems: 

1. Automatic Message Accounting Teleprocessing System (AMAT'S) 
2. Automatic Message Accounting Recording Center (AMARC) 

3. 2 Switching Control System Center (2SCCS). 


5.6.2 Essential ac cabinet 


The essential ac cabinet contains the following systems: 

e Central Trunk Test Unit (CTTU) 

e Engineering and Administrative Data Acquisition System 
(EADAS) 

e Remote Memory Administration System (RMAS) 

e Service Evaluation System-2 (SES-2) 

e Recent Change and Verify Local (RC/V LOCAL) 
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e Software Change Administration and Notification System 
(SCANS) 

e Automatic Line Insulation Testing Repair Service Bureau (ALIT 
RSB) 

e Verify Repair Service Bureau Local Test Desk (VFY RSB LTD) 

e Belt Line (TTY A&B) 

e Recent Change and Verify Switching Control Center (RC/V- 
SCC) 

e Recent Change and Verify Network Administration Center (RC/ 
V-NAC). 


5.7 Remote switching module 


The Remote Switching Module (RSM) is an SM located remotely 
from a host 5ESS switching equipment office and connected via T1 
carrier facilities. An RSM is a 5ESS switching equipment SM connected 
by digital facilities through a Facilities Interface Unit (FIU) to a host 
5ESS switching equipment multimodule office. The RSM is capable 
of terminating lines and pair gain systems. The RSM can be divided 
into the following equipment types. 


5.7.1 Digital facility interface 


The RSM Digital Facility Interface (R-DFI) consists of a group of 
circuit packs that plug into a DCLU and act as an interface between 
the T1 lines from the host office and the FIU. 


5.7.2 Facilities interface unit 


The FIU consists of several subunits. These subunits are Multiplexers 
(MUXs), LIs, and a Clock Control (CLK CNT). The FIU recovers 
data, control, and timing from the T1 line and formats this information 
into a pair of NCT link signals that it routes over fiber-optic pairs 
called NCT links to the RSM SM (see Fig. 22). 


5.7.3 Switching module 


The RSM SM consists of the following units: 

1. Time-slot interchange unit 

2. Switching module processor unit 

3. Modular metallic service unit 

4. Digital service unit 

5. Interface units—line units, trunks units, and DCLU, as required. 


5.7.4 Optional equipment 


Optional equipment for the RSM includes the 13A Recorded An- 
nouncement Unit (RAU) and Directly Connected Test Unit (DCTU). 
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Fig. 22— 5A remote switching module. 
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Fig. 23—5A remote switching module with 1024 line terminations. 
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Fig. 24—MCC/TLWS console. 


5.7.5 Other equipment 


Other equipment includes an Office Repeater Bay (ORB), DSX-1 
digital cross-connect facility, battery plant, distributing frame, etc. (see 
Fig. 23 for 1024 RSM equipment). The ORB supplies signal equalization, 
regeneration, and T1 line powering. The ORB is connected to a DSX- 
1 facility that provides test access to the T1 lines. 


5.8 Master control center/trunk line work station 


The MCC provides the interface capability for both administrative 
and maintenance tasks. The MCC is the primary communication link 
between maintenance personnel and the 5ESS switch. The Master 
Control Center/Trunk Line Work Station (MCC/TLWS) console (see 
Fig. 24) and MCC/TLWS 6-foot cabinet (see Fig. 25) contain the 
following major components: 

1. Video Display Terminal (VDT) with keyboard (color terminal 
option is also available) 

2. Receive-Only Printer (ROP) 

3. Multiline Telephone Set (MLTS) equipped with loudspeaker 

4. Test Access Unit (TAU). 

The video display terminal provides the means to communicate with 
the system during performance of a maintenance task. Maintenance 
requests are input through the keyboard, and the receive-only printer 
prints a hard copy of input and output messages for future reference. 


1480 TECHNICAL JOURNAL, JULY-AUGUST 1985 


AR AR BEY 
aul 












VIDEO "4 
DISPLAY 
TERMINAL 


MULTILINE 
TELEPHONE 4 
| P RECEIVE- 
weg ONLY 


Fe 


- 
SLIDING | 


DRAWER 
(BLUE) 


BOOKSHELVES © PRINTERS’ 
INSIDE PAPER 
COMPARTMENT 





Fig. 25—MCC/TLWS/STLWS cabinet. 


The MLTS is used to provide a general-purpose business line, and a 
TEL A Mon and TEL B Mon line, which is used to provide testing 
of the network. The MLTS can be used independently of the same 
central office, thereby ensuring outside communication during office 
outage. The MLTS is equipped with a loudspeaker to provide voice 
communication when maintenance personnel require hands-free 
operation. 

The MCC/TLWS shares the same physical equipment as a fully 
equipped Supplementary Trunk Line Work Station (STLWS). The 
ROP, MLTS, and TAU are optional equipment for the STLWS only. 

The STLWS enables a 5ESS switch to be equipped with additional 
TLWSs (maximum of six) that are separate from the MCC. The 
operating company can then separate trunk and line testing activity 
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from the MCC so that several crafts people can work simultaneously 
at different work stations to speed up the precutover testing. 

Additional test equipment can perform some TLWS functions. The 
TAU provides several plug-in type jacks, which are used with portable 
test equipment and system software control to gain trunk or line 
access and perform tests. The MCC input/output and display conven- 
tions are also used by the TLWS. Although the TLWS and MCC 
share the same equipment, functional differences exist between them. 
These differences include the MCC functions mode and the TLWS 
functions mode. The TLWS functions are subfunctions of the MCC. 
Normally, the equipment is in the MCC mode. When performing 
TLWS functions, the equipment is switched automatically to the 
TLWS mode. 
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The 5ESS Switching System: 


System Development Environment 


By R. G. BASINGER, J. A. HERNDON, B. KASKEY, J. A. LINDNER, 
and J. M. MILNER* 


(Manuscript received October 13, 1983) 


This article describes the elements of the system development environment 
that support each phase of the 5ESS™ digital switching system product 
development. The elements themselves are complex hardware/software systems 
that are specialized to meet the particular needs of the different phases of 
development but integrated to smooth the transition through the phases. The 
requirements and design phases are supported by general-purpose UNIX™ 
systems that provide a rich set of tools for document preparation. The design 
is transformed into executable software for the 5ESS system, primarily in the 
C programming language, augmented by C-based extension languages to 
support the special needs of database and diagnostic programming. This 
software is created, compiled, combined, and packaged for the 5ESS switch 
test models by large UNIX systems running on IBM System/370-compatible 
hardware. Unit testing of developed software takes place on smaller support 
computer systems in an environment that closely resembles the test model. 
The test models, actual 5ESS switching systems, are used for the integration 
and system test of the product. A dedicated computer system for each test 
model supports testing at the C language level. A number of actual and 
simulated load generators are used to stress and regression test the system. 
All the support systems are interconnected with high-speed data transmission 
networks that support remote command execution as well as file transfer. 


I. INTRODUCTION 


Since the early 1960s AT&T Bell Laboratories has been developing 
and introducing large software packages that operate, maintain, and 
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administer the many types of electronic switching systems that make 
up the major portion of the telephone switching network in the United 
States. As these packages have grown in scope and complexity, there 
has been a parallel growth in the use of computers and computer- 
based aids to support each system. For the 5ESS digital switching 
system, this collection of computer aids, with its development elements, 
is known as the System Development Environment (SDE).* The 
elements are complex hardware/software systems that are specialized 
to meet the particular needs of the different phases of development 
but integrated to smooth the transition through the phases. The 
requirements and design phases are supported by general-purpose 
UNIX systems that provide a rich set of tools for documentation 
preparation. The transformation of the design into executable software 
for the 5ESS switching system is done primarily in the C programming 
language, augmented by C-based extension languages to support the 
special needs of database and diagnostic programming. This software 
is created, compiled, combined, and packaged for the 5ESS switch test 
models by large-scale UNIX systems. A dedicated UNIX system for 
each test model supports testing at the C language level. All elements 
are tied together with high-speed data-transmission networks. 

The 5ESS system architecture and the development approach 
provide new challenges that are met by the SDE. The software in the 
5ESS system is distributed over several different types of processors, 
and the architectural design is such that as new processors are 
developed they can be substituted into the basic system. This means 
that the development environment must be able to assign software to 
the designated processors and must make it easy for existing software 
to be applied as technology changes both during development and 
after the system is released for commercial service. Software may be 
located in writable memory or in read-only memory. The development 
environment must always associate the correct software and firmware 
(software in read-only memory) for each load or release of the system. 
The development plan provides for many organizations to be generating 
software simultaneously for different releases of the system. This 
means the development environment must allow for parallel develop- 
ments with overlapping content and independent schedules for actual 
releases. 

The environment operates under a formal methodology for each 
step in the process and supports the generation of complete documen- 
tation for all phases of development from requirements to system 
release. All source and object code is controlled and tracked for each 
development version of the system as well as for each officially released 


* Acronyms and abbreviations used in the text are defined at the back of the Journal. 
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version. The environment allows the 5ESS system design to evolve by 
sequentially adding capabilities that can be independently developed 
and tested. The environment also allows continued maintenance of 
the system by applying incremental updates to the software. Overall, 
the SDE gives the programmers their individual, personal contact to 
the system under development without the programmers being hindered 
by the hundreds of other programmers and developers accessing the 
system. 


Il. PROGRAMMER SUPPORT SYSTEM 


The Programmer Support System consists of all components needed 
to facilitate the work of the software developer during the requirements, 
design, and software-generation phases of the development life cycle. 
In the 5ESS SDE the requirements and design phases are supported 
on medium-scale, general-purpose computing facilities, and the software- 
generation phases are supported on large-scale computing facilities. 
The medium-scale systems are either AT&T 3B20S or VAX-11/780* 
machines running the UNIX operating system and are typically 
referred to as general-purpose UNIX systems. The large-scale software- 
generation machines are IBM 3033AP, IBM 3081K, or Amdahl 5860 
systems, also running the UNIX operating system. These are referred 
to as Large-Processor (LP) machines. 


2.1 General-purpose UNIX systems 


The 5ESS switch methodology relies on a series of well-defined 
specification documents to guide the development process. These 
documents include architecture, requirements, capability design, de- 
velopment unit design, and test-plan specifications. A standard template 
outline has been defined for each document, and the developer uses 
the general-purpose UNIX facilities to create and maintain these 
documents. 

Several sophisticated tools exist in the UNIX environment to 
support this document generation. The Programmer’s Workbench and 
Writer’s Workbench™ systems provide tools that perform such tasks 
as spelling verification, double-word detection, sentence structure anal- 
ysis, and readability analysis. In addition, there are tools that allow 
the writer to transform text into well-formatted, publication-quality 
documents. These tools include nroff, a macro language for formatting 
text; tbl, a tool to create tables; and gc, a tool that formats “typewriter 
art” into polished figures. The 5ESS switch project’s general-purpose 
computing resources are supplied through the computer center opera- 
tions that support the general AT&T Bell Laboratories user community. 


* Trademark of Digital Equipment Corporation. 
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2.2 Large-processor UNIX systems 


The majority of the Software Generation System (SGS), source 
control, and Change Management System (CMS) functions are per- 
formed on the LP UNIX systems. The LP systems run the UNIX 
operating system and, in addition to the standard rich set of tools 
provided with the UNIX operating system, support several major piece 
parts integrated through well-defined procedures and scenarios. The 
process of software development proceeds from the initial writing of 
the software to its official introduction under source control. At this 
point the source can be compiled and introduced into a product 
package of varying size for execution and testing in either the Execution 
Environment (EE) (see Section III) or test-model target machines. It 
can then be changed in a controlled way throughout its initial 
development. After being introduced into the field it can be supported 
and updated. The tools to support these steps in the software life cycle 
will now be described. 


2.2.1 Change Management System 


The CMS provides the ability to keep track of the current version 
of the official program source, isolate test versions of programs, and 
eventually introduce either new code or corrections into the official 
version of 5ESS system software. The CMS provides not just isolation 
of changes in differing states of development but also independence of 
one generic from another. It can also provide dependence of one 
generic on another by allowing pieces of the software to be defined as 
common between multiple generics. The software for the 5ESS switch 
is partitioned into a number of logical subsystems, each of which 
performs a part of the total switching task. The software for each 
subsystem is organized in a structure that can be cleanly represented 
as a subtree of the UNIX file system’s tree-structured directory 
hierarchy. These structures, known as nodes, are understood by the 
CMS system and the load-building tools. The subsystems are spread 
across several LP UNIX machines; however, no single subsystem 
spans more than one machine. Each subsystem is built (compiled) 
independently and then collected on a single machine designated as 
the Program Administration machine for final building (link editing). 


2.2.2 Software generation systems 


There are several SGSs in use to support cross-compilation to a 
multiplicity of target machines; System/370 compatibles, AT&T 3B20, 
VAX-11/780, Intel* 8086, Motorola MC68000, and several smaller 
microprocessors. 


* Registered trademark of Intel Corporation. 
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The SGSs consist of preprocessors, compilers, optimizers, assemblers, 
linkers, and utilities. Preprocessors have been developed to provide 
enhanced message and data definition capabilities to the developers. 
They provide a higher level of abstraction and better user interface 
for the definition of interprocess and interprocessor communications 
and the definition of database relations. The output of these prepro- 
cessors is C language code. 

The vast majority of 5ESS system software is written in C, and the 
portable C compiler provides the basis for the multiple-target-machine 
environment support. A tool, lint, is provided for syntax, portability, 
and interface checking of the source code before compilation. Listing 
production is a separate process and can be accessed on-line. Optimizers 
have been provided for real-time and memory optimization of code 
targeted for the AT&T 3B20D Administrative Module (AM) processor 
and the Motorola MC68000 Switching Module (SM) processor. 


2.2.3 Load building and packaging 


Using CMS and SGS to create a desired version of the system 
source and process it into object files, the load-building process brings 
together the work of developers to produce an official load for testing 
in the test models. Using an automated Initial Modification Request 
(IMR) system, developers record their progress during the development 
of a new capability or the correction of a previously detected problem. 
When the developer has completed the necessary software changes 
and tested the changes privately, the developer submits the IMR to 
the load-building team for inclusion in one or more public loads (a 
change may belong in two or more load streams because of shared 
development). Using information recorded in the IMR, the load- 
building team extracts the desired version of the affected source 
without interfering with other ongoing change activity. Using a series 
of recipes for product construction, known as makefiles, and a series 
of node structures that represent the current view of the load, the 
necessary source-to-object transformations are automatically performed 
in a selective fashion. Only those transformations that must be 
repeated because of changes introduced by new IMRs are performed. 
This process, known as load building, takes place in parallel on all the 
LP machines for all subsystems. Shared information necessary for all 
subsystems, such as global header files and common data definitions, 
are preprocessed and distributed to all LP machines via the interpro- 
cessor network (see Section VII), utilizing a set of shipping tools that 
ensure the integrity of the distributed data. Once the load building on 
each machine has produced a single object file for each combination 
of processor type and subsystem, these high-level objects are shipped 
to a single LP machine and combined to form the final products, 
which are then delivered to the test models. 
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A more incremental development process that only reconstructs 
lower-level products is used by developers to produce private products 
for testing code before its official introduction. Two methods, called 
capability build and Quick Fix, allow the developer to build a private 
test product on a capability basis, rebuilding only those parts of the 
subsystems needed for the capability and thus introducing a small 
change into the test model without rebinding entire subsystems. 

In addition, a set of tools has been developed that allow fixes to be 
quickly and efficiently introduced into generics in the field. These tools 
extract from updated object files the functions and data that have 
been changed with respect to the field, package the minimal changes 
with associated installation instructions, and transmit the resulting 
package via electronic delivery to affected sites. At the field sites the 
package is further processed and installed in in-service offices, without 
disruption of service. Associated listings are produced and available 
for field offices. 


Ill. EXECUTION ENVIRONMENT 


The EF for the 5ESS system uses general-purpose UNIX systems 
to host a simulated 5ESS system environment. Using a standard 
library of subroutines to stub off the routines that directly control and 
monitor hardware in the actual switch, the users of the EE can test 
the logical behavior of the vast majority of the operational software 
from their desks. Since the software to be tested is written in C, all 
that is required to build a load to be tested in the EE, rather than a 
test model, is to compile the code for the AT&T 3B20S rather than 
the AT&T 3B20D or Motorola MC68000. To support this mode of 
testing, the official load-building process produces loads for the EE as 
well as the test models. Using additional software provided with the 
KE, the user can test code destined for either the AM or SM or both. 
The testing language used is identical to that which the developer will 
use later in the test model. Test scripts can be developed and refined 
in the EE and then taken directly to the test model for regression 
testing on the actual hardware. By using the EE for unit and small- 
scale integration testing, users can isolate and correct logical problems 
before entering the test model. The use of general-purpose processors 
to support the EE reduces the complexity of parallel hardware/software 
development by allowing most software problems to be found and fixed 
before the code is executed on the switch hardware. 


IV. LABORATORY TEST SYSTEM 


The Laboratory Test System (LTS) for the 5ESS system gives 
software developers a friendly environment in which to test their code. 
It does this by providing a standardized command language and by 
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interfacing the various test products to the 5ESS subsystems through 
a single Laboratory Support Processor (LSP). The software under test 
is resident on one or more of the processors within the distributed 
architecture of the 5ESS switch. 

In general, LTS test products have an LSP-resident part and a 
5ESS switch-resident part, some of which require special hardware 
interfaces to the switch. The LSP part controls the switch-resident 
part and communicates with it over data links so that the LSP can 
be located remotely from the switch. 

The LTS is an evolving system with multiple capabilities. It is 
packaged and distributed to users as a single system. Test-product 
improvements and new test-product capabilities are scheduled and 
developed based on the prioritized needs of the entire 5ESS system 
development community. LTS is provided in tested and scheduled 
releases. Each release is accompanied by installation documentation 
and is installed in a 5ESS system laboratory soak site by an installation 
team supported by an LTS first-application team. After a suitable 
soak interval the release is distributed to all system laboratories by 
laboratory support personnel. Procedures are available to give emergency 
fixes or interim releases to solve problems identified by the user 
community. New releases are accompanied by user documentation and 
by tutorials presented by the LTS developers. 


4.1 Laboratory support processor 


The LSP, running the UNIX operating system, provides the facilities 
to interface the test products to the users in a standard format. This 
standardization of format reduces the training required for users to 
become productive and also reduces user errors. 

The LSP controls test resources and may be configured to handle 
dozens of user terminals that are either dial-up or directly connected. 
A single LSP can serve several 5ESS switch test models simultaneously. 

Software to be tested is prepared on the LP systems, transferred to 
the LSP via the Network Systems Corporation network (see Section 
7.2), and then loaded into the target 5ESS switch processor under 
control of the LSP. A different symbolic debugging tool is needed for 
each type of 5ESS switch target processor (AT&T 3B20D, Intel 8086, 
or Motorola MC68000), but the user interfaces to these tools are 
essentially identical. 

The LSP file system contains copies of all approved 5ESS switch 
object code and symbol tables relating it to the C language source 
code. In addition, the file system contains object modules and corre- 
sponding symbol tables for the new code to be tested. The symbol 
tables are used for symbolic debugging. Any of the software object- 
level files can be loaded into an appropriate target processor in the 
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5ESS switch for testing. Frequently a test session will require software 
to be loaded into two or more target processors, each of which is 
monitored with a separate user terminal connected to the LSP. 
Symbolic test results or memory dumps can be transferred to the LSP 
for detailed analysis. 

The LSP supports the use of test scripts for code debugging or 
regression testing. It makes available test products that allow scripts 
to generate switching system stimuli in the form of various types of 
line and trunk calls, high call-traffic volumes, or simulated craft input 
messages. Switching system response is then monitored via standard 
system outputs—e.g., traffic schedules or teletypewriter messages—or 
via special test software loaded into the target processor by the LSP. 

Figure 1 is a diagram of the combined 5ESS switch-LTS configuration 
showing that the LSP communicates via data links with various 
hardware subsystems within the distributed architecture of the 5ESS 
switch. These subsystems are the AM, the Communications Module 
(CM), and multiple SMs. Three types of processors are used within 
the current 5ESS switch. The AM uses an AT&T 3B20D processor, 
the CM uses Intel 8086 microprocessors, and SMs use Motorola 
MC68000 microprocessors. The numbers within each box of Fig. 1 
indicate the LTS products that are available for each 5ESS subsystem. 

Four LTS products that reside entirely on the LSP are not shown 
on Fig. 1. They are the UNIX operating system, the software to 
interface to the Network Systems Corporation high-speed data bus, a 
C language-level software correction capability (Quick Fix), and an 
object-level software correction capability (Patch Compiler). 


4.2 Test subsystems 


The LTS test products fall into three broad categories. The first 
category is load administration facilities. The second is software 
debugging tools, which include C language debuggers for each of the 
processor types, coverage analyzers to determine the percentage of 
code actually executed, a Communication-Link Monitor (CLM) for 
recording and analyzing messages passed between 5ESS subsystems, 
and a system-pause capability to permit all processors to be halted 
and restarted simultaneously under control of the software debugging 
tools. The third category is test products, which provide 5ESS system 
stimuli in the form of call traffic, intersubsystem message traffic, or 
craft input message traffic. 

The Debugger for Remote Target (DART) and the Integrated Test 
System (ITS) are C language debugging tools that allow the user to 
plant breakpoints, modify memory or processor registers, and provide 
formatted symbolic dumps of software variables and symbolic traces 
of software execution. Many of the actions of these debuggers interfere 
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Fig. 1—LTS configuration for the 5ESS switch. 


with the normal real-time execution of 5ESS system code and are not 
suitable for use in an in-service environment. ITS, however, does 
provide extensive debugging capabilities on a noninterfering basis. 

Coverage Analyzers (CAs) are provided to determine what percentage 
of the code is executed. The CAs work in conjunction with compiler 
options that plant instructions in the object code to flag a specific 
memory location in a CA map when that code is executed. The LTS 
part of the CA function then retrieves the memory location map and 
produces a symbolic display of the code that has been executed. The 
mapping can be done either on a function-by-function basis or on a 
line-by-line basis. 

The CLM requires a special circuit that taps into the 5ESS switch 
message links at the CM and at one or more of the SMs to permit 
the LTS to capture selected messages or message headers for analysis. 
The CLM circuit also contains a display for local monitoring of the 
messages. 

System pause is a function not presently integrated into the LSP. 
It consists of (1) circuits that interface with each processor in the 
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system and (2) an array of switches and lamps. The switches are used 
to select which processors will be enabled for a specific test, and the 
lamps display whether the associated processor is halted. A development 
currently under way will replace the manual switches with ones that 
can be remotely controlled by the LSP. 

Call traffic is generated by programmable call simulators that 
contain (1) circuits that simulate lines and trunks and (2) circuits that 
can generate and detect tones and various types of telephone signaling. 
These line and trunk circuits interface to the 5ESS system SMs as 
standard lines and trunks, and calls generated by the call simulator 
appear to the 5ESS switch to be normal calls. Test scripts are written 
in a C-like simulation language and stored in test sequence files on 
the LSP. A wide variety of line and trunk calls are possible. These 
test scripts are extensively used for regression testing of the 5ESS 
system generics. 

The Load Originating Test System (LOTS) generates high-volume 
message traffic, which appears to the AM as coming from a number 
of SMs in the 5ESS switch. In reality, the messages are generated by 
special software loaded into Module Message Processors (MMPs) in 
the CM subsystem of the 5ESS system. The messages generated by 
LOTS simulate line-to-line, line-to-trunk, and trunk-to-line calls that 
represent either inter-SM or intra-SM traffic. The messages may 
represent completed calls, abandoned calls, Custom-Calling calls, or a 
variety of other call-sequence situations. In addition, the LOTS 
software generates corresponding traffic data and AMA billing data, 
which it sends to the AM for processing. Each LOTS MMP can 
generate messages representing approximately 70,000 busy-hour calls. 
With four MMPs, LOTS is able to load the AM with message traffic 
representing close to 300,000 busy-hour calls. 

The Craft Message Generator/Analyzer (CMGA) is a test product 
that interfaces to serial I/O channels of the AM, such as the mainte- 
nance channel or service-order channel. The CMGA generates tele- 
typewriter traffic on these serial channels and records the system 
responses for analysis. Test scripts can be generated and stored on the 
LSP, and the 5ESS responses can be matched against the expected 
results. 


V. TEST MODELS 
5.1 General description 


The fundamental purpose for the test models in the 5ESS system 
development environment is to allow programmers to debug their code 
on the target machine. Subsequent software integration, load stress 
testing, stability runs, and final generic verification are also accom- 
plished on a configuration that is representative of expected capability 
interactions in the field. Additionally, the test models integrate the 
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hardware design into the software architecture to satisfy the overall 
system requirements. In this manner, the test models simulate the 
latest state of the hardware to allow the software to execute and 
operate under the expected conditions that will be seen in the field. 

The test model simulates an operating local telephone office with as 
many of the myriad combination of features and capabilities as are 
required to test the generic being produced. For feature debugging 
purposes, there is a subscriber test station, which allows manual 
testing of line features (e.g., dial pulse, Touch-Tone, coin) via the 
appropriate station set access. The subscriber test station also allows 
manual access to a variety of trunks for testing of transmission and 
signaling features of the 5ESS switch. Automated load test equipment 
is also provided for simulated traffic effects to test the real-time 
capacity and system response of the software architecture. 

In addition to the target machine and the LTS, the 5ESS system 
test models are also equipped with a user area to create a friendly 
environment. When this space was planned, considerations ranged 
from furniture to a complete simulation of the field Master Control 
Center (MCC). Cabinets, tables, computer terminals, phones, and 
other appointments were considered in establishing an environment 
conducive to the development effort. Access to the LTS as well as the 
LP and general-purpose UNIX systems is provided via direct lines 
and dial-up service. Figure 2 displays a 5ESS system test-model user 
area, showing the LTS user terminals and the MCC in the foreground 
with the 5ESS switch itself behind the glass partition. 


5.2 Lab engineering 


The detailed configuration of a given test model is generated from 
requirements provided by the development organization in a fashion 
analogous to the dial administrator and equipment engineering functions 
in an operating company. This hardware and the associated engineerable 
assignments are represented in the executable software in the office- 
dependent data. Changes to this software abstraction of the peripheral 
hardware must be coordinated with changes to software tools altered 
by the target code, changes to the hardware configuration, or changes 
in assignments within a test model. This interaction of the office- 
dependent data with the state-of-the-generic development is one major 
aspect of the test-model work to ensure the integrity of the hardware 
as viewed by the target software. 


5.3 Load procedures 


The developing software takes on the character of a generic through 
addition and update of the various pieces into an integrated whole 
called a load. The test models provide the environment for maintaining 
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a load of a particular vintage, termed the public load, and bringing in 
new loads on a schedule commensurate with developer needs. Each 
public load may encompass software and, possibly, hardware and 
firmware changes in the evolution toward a field-grade generic. Addi- 
tionally, the test models allow altered states of these public loads, 
termed private loads, to be tested by individual programmers for 
specific situations. 


5.4 Developer testing 


The individual developer testing with private loads is the essence of 
the proof that the capability under development meets the intent of 
the requirements. The test-model environment provides the necessary 
hardware and software tools to allow the programmer to test, debug, 
alter, and retest the code under examination to the satisfaction of the 
documented test plan. The foundation of these private loads is the 
previously mentioned public load, against which the private loads are 
built. The programmer private-load mechanism begins in the LP 
environment with the public-load structure and manifests itself in the 
private software under test. As each capability is proven to meet the 
requirements in this environment, all the individual capabilities are 
reconstituted together to form the next public load. This synthesis of 
numerous capabilities into the new thesis of a public load is then 
regression tested to produce information relating to interactions among 
the various capabilities added to the developing generic. 


5.5 Load testing 


A subset of the test models is configured for regression and load 
testing of the public load. This mechanism of stress testing the 
software via simulated high-level telephone traffic has consistently 
generated heuristic information that uncovers latent problem interac- 
tions in the generic load. System testers and private-load developers 
take advantage of programmable call-simulation equipment to provide 
mixtures of ordinary and feature-activating telephone calls up to and 
beyond the design capacity of the system to tune system behavior at 
all traffic levels including overload. 


5.6 Lab maintenance 


As a final note, the public load is used as the vehicle to maintain 
the test-model environment at a satisfactory level. Such maintenance 
time is used to fix problems uncovered throughout a given period, 
apply official change notices issued against the hardware, evolve and 
grow the hardware according to agreed-upon development plans, and 
reaffirm the stability of the test model with the appropriate features 
in the public load. As always, this maintenance activity is balanced 
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against the need for the test model as a system development resource 
and trade-offs are constantly being made in the fast-paced development 
environment. 


VI. SPECIAL-PURPOSE SYSTEMS 


In a system the size and scope of the 5ESS switching system, a 
number of functions require special facilities or benefit from novel 
uses of computer systems. The applications described in this section 
are examples of special-purpose systems in use by 5ESS system 
development. 


6.1 SCANS 


The Software Change Administration and Notification System 
(SCANS) provides a gateway between the 5ESS SDE and the AT&T 
Technologies field-support network. Updates to software running on 
in-service 5ESS switches are produced as explained above and then 
sent to the SCANS machine for packaging and transmission to the 
field. The SCANS machine, interconnected to the other 5ESS system 
development systems via an interprocessor network outlined below, 
focuses the necessary hardware and software for this task in a single 
machine but gives the whole project access to the field-support 
function. 


6.2 Project management 


The coordination and control of a large development project such 
as the 5ESS switch requires considerable computer support. Dedicated 
systems with associated tools are used to track and report on the 
progress of development; maintain lists of action items and resolutions; 
and maintain and distribute paper and electronic copies of architecture, 
methodology, and schedule documents. An ever-increasing variety of 
graphics applications have been developed to capture and represent 
the plans and status of the project. 


6.3 System-testing support 


To ensure a quality product, extensive system-testing activity is 
performed on the 5ESS switch. A dedicated computer system is used 
to store and track the status of the large battery of regression tests 
that have been developed for the switch. Electronic logging and 
automated analysis of output messages from 5ESS switches also are 
routinely provided. 


Vil. NETWORKS 


The 5ESS system development involves hundreds of software de- 
velopers at several AT&T Bell Laboratories locations. Support of this 
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number of developers requires several dozen computer systems that 
must be connected to both the developers and each other. 


7.1 Terminal networks 


To interconnect each developer with the computer systems that he 
or she may require in the course of a day’s work is itself a major task. 
To meet this need the 5ESS system development presently is using 
three approaches: Dimension® Custom 2000 PBXs, Develcom, and the 
Datakit® virtual circuit switch. 


7.1.1 Dimension Custom 2000 PBXs 


The primary site for 5ESS system development is a complex of 
large buildings in a campuslike setting. Each developer is provided 
with dial-up access to all computers in the complex via a network of 
Dimension Custom 2000 PBXs dedicated to data switching. The most 
common connection is currently 1200 baud, although faster and slower 
rates are possible. This network is part of a larger companywide voice 
and data switching network that provides flexible access to computer 
systems at all company locations. 


7.1.2 Develcom 


To provide switched but nonblocking access at higher speeds to 
replace point-to-point connections previously used, a small data switch 
has been installed. These lines are used primarily by hardware devel- 
opers to interconnect proprietary microprocessor development systems 
and programmable read-only-memory programmers to other computer 
systems. 


7.1.3 Datakit virtual circuit switch 


To provide widely available very-high-speed access from all potential 
users to the computer systems, a Datakit virtual circuit switch local 
area network is being introduced. This network will eventually supplant 
the Dimension PBXs as the primary access to all local computer 
systems and provide gateways to Datakit virtual circuit switch networks 
at other company locations. The bandwidth available with this approach 
is matched to the needs of intelligent terminals and work stations now 
finding their way into the project. 


7.2 Interprocessor network 

File transfer between the development-support computers is provided 
by the HYPERchannel* network and associated adaptors. The network 
consists of two dual-coaxial-cable backbones, one in each of the 


* Trademark of Network Systems Corporation. 
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primary development buildings, interconnected via dual fiber-optic 
links. Further extension and complete interconnection of the networks 
is provided by a gateway system, which transships files between 
subnetworks. Connections are supported to AT&T 3B20S, PDP-11/ 
70,* VAX-11/780,* and System/370-compatible machines. Data rates 
on the 50-Mb/s buses range from about 3000 to over 100,000 bytes/s, 
depending on the combination of source and destination machine types 
and loads. Networking software in each connected processor controls 
access to the buses and provides for transmission of files, execution of 
commands on remote systems, and notification of file delivery or 
command results. The file transfer mechanism is used to propagate 
changes in the 5ESS system software being developed across support 
systems. It is also used to deliver code from the LP systems to the EE 
or LTS systems for testing. Updates to the UNIX operating system 
and 5ESS system tools are distributed via the network, and performance 
data on the support computers and the network itself are collected via 
the network. Remote execution of commands allows a user on one 
system to perform activities on another system without logging into 
the second system. 


7.3 1/0 network 


The 5ESS switch project uses a network to access high-speed-laser 
page printers for publication-quality documentation, plotters for graph- 
ical data, and specialized resources such as a Cray supercomputer. 
This network also provides an alternate path between 5ESS system 
support machines via the remote-job-entry network. Electronic mail 
may be routed via this network to any computer system within the 
company. A form of limited remote command execution also exists for 
this network. 


VII. CONCLUSIONS 


A system development environment that allows generation of high- 
quality software, ensures high productivity of programmers, and provides 
administration of all versions of the system has been developed. The 
environment has been able to evolve as required by the 5ESS system 
architecture and development plan. This has been achieved by using 
a distributed architecture much like the 5ESS switch itself, where 
growth can be accomplished by adding computing and testing elements. 
Contributing to the ability to gracefully evolve is the versatility of the 
UNIX operating system and the C language, which is the base for the 
environment as well as the 5ESS switch. The importance of a formal 


* Trademark of Digital Equipment Corporation. 
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methodology cannot be overlooked. The 5ESS system project can be 
expected to continue to rapidly add features and capabilities for many 
years using the SDE. 
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Comprehensive system testing and verification of feature design at a “first- 
office”-application site are integral parts of the design and development 
methodology for the 5ESS™ system. The strict enforcement of this methodology 
has led to a product that has exhibited high quality and reliability in the field. 
This paper describes the activities associated with the integration and system 
testing of 5ESS system generics, as well as the procedures used at the first- 
office-application site to verify operational compatibility prior to release for 
service. The operational experience with in-service 5ESS systems is also 
described. 


I. INTRODUCTION 


Since the introduction of the first multimodule office in Sugar 
Grove, Illinois, in 1983, the number of 5ESS systems in service has 
increased dramatically (see Fig. 1). In anticipation of this rapid 
buildup, and the rapid introduction of new designs and features, the 
system was designed to include steps to ensure reliability during 
manufacture and installation. These have made it possible to bring 
systems to the market rapidly. 

During the first two years of 5ESS system service, three major 
system program releases (generics) plus several minor “point” generics 
were designed and released by AT&T (see Table I). Each of these 
generics went through extensive system testing and comprehensive 
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Fig. 1—5ESS switching systems in service. 


verification of operational performance and customer acceptance at a 
First-Office-Application (FOA)* site. 

This paper describes the activities of system integration, system 
test, and FOA-site verification. The methodology for 5ESS system 
development is briefly described in Section II. System integration 
activities are described in Section III. Section IV describes the functions 
of system test, while Section V describes the activities at the FOA 
site. The field experience with the early 5ESS switch is described in 
Section VI. 


Il. DEVELOPMENT METHODOLOGY 


Generics for the 5ESS system are created following a strict meth- 
odology for both hardware and software development. Using this 
methodology, specific milestones for each of the development and test 
phases are established for completion within a specified time frame. A 
representation of the methodology is shown in Fig. 2. The design 
organizations are responsible for the capability design, design-unit 
design, coding, unit test, and capability test. System test, regression 
test, and FOA verification are the responsibility of separate test 
organizations. 


* Acronyms and abbreviations used in the text are defined at the back of the Journal. 
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Table I—Generic development 


Service Date Generic Issue Principal Features 
3/82 5E1(1) Basic single module 
3/83 5E1(1A) Improved module processor 
8/83 5E1(2)1.0 Multimodule system 
10/83 5E1(2)1.1 Local/toll 
2/84 5E1(2)1.2 Improved network fabric 
4/84 5E1(2)2.0 Remote switching, integrated SLC® carrier system 
6/84 5E1(2)2.1 Module growth, optically integrated Remote 
Switching Module (RSM) 
9/84 5E1(2)3 Frequency-selective ringing, RSM trunking 
4/85 5E2(1) Carrier interconnect, basic Centrex 


Early in the planning for a 5ESS system generic, each feature 
approved for development is divided into “capabilities.”: A capability is 
a specific software or hardware function. For example, capabilities 
needed to implement the feature “three-way calling” would include a 
conference bridge, a special digit-handling program, and a data-change 
program for three-way-calling parameters. A specific schedule for 
completion of the development and test phase for each capability is 
established. A project management group tracks and reports milestone 
completions (see Ref. 1). 


Il. SYSTEM INTEGRATION 

System integration plays a central role in the overall development 
of 5ESS system generics. System integration includes program change 
control, software-load building, system-load bringup, and field delivery. 
System integration teams are formed early in the generic development 
cycle and work closely with the project management, feature planning, 
and test groups to establish an integration plan for the generic. This 
plan includes the requirements for the system-lab test equipment and 
configuration, program-support environments, and specific schedules 
for the development, testing, and delivery of the features required for 
the generic. The integration team’s main responsibility is to ensure 
that a stable development and test environment is maintained as 
major software functions are added to the generic. 


3.1 Program change control 


Integration of code added to the generic is overseen by the Program 
Change Committee (PCC). In this way, the PCC ensures that generic 
stability is maintained as new features are added. The PCC is chaired 
by the integration team and has representation from all the software 
development areas as well as system-test and site-test groups. The 
PCC approves the software changes introduced into the generic. During 
the early stages of a new generic development—when major software 
functions are being coded—the PCC reviews the integration and 


SYSTEM TEST 1505 







SYSTEM 
ARCHITECTURE 


CAPABILITY 
REQUIREMENTS 
CAPABILITY 
DESIGN 
DESIGN-UNIT 
DESIGN 
CODING 
UNIT TEST 
CAPABILITY 
TEST 
NEW FEATURE 
SYSTEM TEST 


REGRESSION TEST/ 
STABILITY RUNS 
















NEW FEATURE 
SYSTEM - 
TEST PLAN 


FIRST-OFFICE- 
APPLICATION 
TEST PLAN 








CAPABILITY 
TEST PLAN 















FIRST-OFFICE- 
APPLICATION 
VERIFICATION 


Fig. 2—Development methodology. 


testing plans for the new code and any accompanying data changes. 
Near the end of the generic development cycle, most of the software 
changes are fixes for bugs uncovered during system and site testing. 
During this period, the PCC reviews all software changes introduced 
into the generic. 

An automated problem-tracking system allows the PCC to review 
and manage software-change activity. All software problems or design 
deficiences that are found or detected are documented by an Initial 
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Fig. 3—Problem status history. 


Modification Request (IMR) that describes the specifics of the problem 
or affected software. The PCC assigns priorities and responsibility 
to IMRs. 

A Modification Request (MR) is used to document the actual 
software submitted for the generic. When the code represented by an 
MR is added to the generic, the associated IMR is closed. The PCC 
regularly publishes reports that summarize the open and closed IMRs. 
The number and seriousness of open IMRs are used to evaluate the 
software quality. The history of open and closed IMRs for a typical 
5ESS system generic is shown in Fig. 3. 


3.2 Program administration 


Part of the integration plan for a generic is a set of regularly 
scheduled software loads that allow incremental introduction of new 
software and subsequent software fixes. Each software load contains 
all the old software plus any new code or corrections approved by the 
PCC. The generation of these software loads is the responsibility of 
the Program Administration Group (PAG). PAG incorporates the 
MRs that are approved by the PCC into the official generic database 
and recompiles the software source code. 

The output of the PAG software-load-building process is a set of 
software files and associated reference documents such as program 
listings and address cross-reference maps. The files contain the exe- 
cutable software for both the Administrative Module (AM) and Switch- 
ing Modules (SMs), plus the Office-Dependent Data (ODD) needed 
for the system-laboratory configuration. 
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3.3 Load bringup 


Hardware and software integration and testing is carried out in 
several system laboratories that, as much as possible, replicate a field 
environment. The process by which a new software load is introduced 
into the system labs is known as load bringup. The integration team 
is responsible for load bringup. After the system lab is initialized with 
the new software load, problems with generic operation are documented 
with IMRs, and, where appropriate, fixes are made to maintain a 
stable environment. A set of comprehensive baseline test scripts are 
executed to verify the integrity of major functions, such as system 
recovery, diagnostics, and basic call processing. At the end of a load 
bringup, major problems and deficiences with the generic are docu- 
mented in a user’s guide, and the system is released to software 
developers and testers. 

Several system laboratories, each with a slightly different equipment 
configuration and test environment, are available for 5ESS system 
development and testing. After a load is brought up and is sufficiently 
stable for testing new code, it is copied into each lab and initialized 
with the lab-specific ODD. Development and test activity then proceeds 
in parallel in several labs until the next load is introduced. 


3.4 Load distribution 


The software loads created early in the development cycle are 
distributed and maintained specifically for the system laboratories to 
support new software design, testing, and evaluation. About three 
months before a system is released to the customer (the turnover 
date), a generic load is needed at the FOA site so that hardware and 
software verification tests can be started. This generic load is designated 
as a prerelease version and undergoes a stringent set of tests to ensure 
its usability in the field environment. Any design deficiences or 
operating exceptions with this load are thoroughly documented for the 
site personnel. 

At the site, the generic program and ODD are loaded in the system 
and initialized. The prerelease load is officially supported by the 
integration team, which provides the fixes designated by the PCC that 
are needed to continue site testing. If necessary, other prerelease 
versions of the generic are sent to the site prior to the official turnover 
load. The official load, along with necessary software documentation, 
becomes the standard release of the 5ESS system by AT&T Technol- 
ogies, Inc. 


IV. SYSTEM-TEST DESCRIPTION 


The 5ESS system is a universal switching system with a distributed- 
hardware architecture and a comprehensive set of features. It is 
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difficult to verify by laboratory testing that the system performs 
correctly under all possible combinations of circumstances. The goal 
of system testing is to rigorously stress each new generic release in 
the system laboratory so that as many errors as possible can be found 
and corrected. The system-test phase includes three types of testing: 
new feature testing to exercise new features, regression testing to 
exercise existing features, and system testing to exercise the system as 
an entity. 

Most system testing takes place in 5ESS system laboratories that 
are configured specifically for system-test use. The system laboratories 
contain a complete, representative set of production hardware so that 
the proper operation of various combinations of hardware can be 
verified. By carefully planning and engineering the installation of 
equipment, an environment can be created that can simulate many 
typical field configurations with a minimum amount of actual hardware. 
In particular, maximum-size equipment configurations are engineered 
whenever possible. 


4.1 Feature testing 


Each new feature or capability of a generic is assigned to a system 
tester, who tracks the development of the feature and reviews feature 
requirements and design. The tester seeks to identify areas where the 
implementation of the feature adversely affects earlier capabilities, or 
where the implementation does not work as it was defined to work. 
To verify a feature, testers use several sources of information, including 
internal requirements (as defined in feature-specification documents 
and capability-requirements memoranda), external requirements (as 
defined in the Local Switching System General Requirements and the 
5ESS System Technical Specification), and user documentation (such 
as AT&T Practices and Telephone Operating Procedures). 

Testers attend appropriate requirements and design reviews and 
provide feedback on all levels of development. This not only allows 
the tester to gain an early working knowledge of the feature, but also 
lets the tester bring a system-level, cross-feature perspective to the 
development process. While the developers are designing and coding 
their capabilities, the testers plan and write the tests to be used for 
each new capability or set of capabilities. The tester also defines and 
writes specific tests to stress system aspects of the capability. System 
aspects include real-time performance, human interfaces, interactions 
with other features, and operation under various abnormal conditions. 
Developers and testers jointly agree on the testing approach and review 
each other’s test plans. 

As part of the testing approach, a set of acceptance tests is defined 
for each capability. The acceptance tests are typically a subset of the 
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system tests. When the developers are satisfied that a capability is 
ready for system testing, they formally deliver it to the system-test 
organization by demonstrating that the capability can pass the majority 
of the acceptance tests. The delivery package includes documentation 
of any failing tests and a plan for resolving them. After the capability 
is delivered, the system tester executes the complete set of system 
tests and records all problem indications. Possible problems are 
analyzed to determine what sequence of events caused abnormal 
responses and whether the problem appears to be an environmental 
(system-laboratory hardware or data) or generic problem. Possible 
generic problems are formally documented with an IMR and referred 
back (through the PCC) to the responsible development organization 
for resolution. 


4.2 Regression testing 


In addition to testing new features, system testers must also test 
existing features to verify that they work as they did in the previous 
generic. Tests that exercise existing features are collected into a 
package of regression tests. As additional features are developed, new 
tests are selected and incorporated into the regression test package. 
Because regression tests are repeatedly executed, they are automated 
whenever possible and are usually executed by specially trained batch 
operators. 

Full regression testing is done after all new capabilities have been 
added to the generic. Regression testing must be done late enough in 
the development interval to catch most problems, but early enough so 
that there is time for the problems to be corrected. 


4.3 Metrics 


System testers keep a detailed account of executed tests and 
uncovered problems. Status is reported periodically. Testers report on 
the number of tests planned, the number of tests executed, the number 
of tests that passed on the first attempt, and the total number of tests 
passed. All problems are identified and tracked, and the corrections 
are retested as they are turned in. . 

Results from the testing of two generics are summarized in Table 
IT. Generic A was virtually a completely new software program; hence, 
the relatively low number of regression tests. Testing productivity 
increased significantly for Generic B; about 20 percent for new feature 
testing and about 50 percent for regression testing. This increase is 
mainly attributable to a more stable system at the beginning of the 
system-test phase, additional test automation, more experienced testers, 
and better test tools. 
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Table II—System-test metrics 


Metric Generic A Generic B 
Number of new tests executed 10,600 7,500 
Number of tests executed per hour 
of test-model time 2.2 2.7 
Noncommentary source lines of 
code tested per test 23 23 


Noncommentary source lines of 
code tested per hour of test- 


model time 50 61 
Number of regression tests 

executed 950 2000 
Number of regression tests 

executed per hour 2 3 


4.4 System testing 


In addition to examining individual features, the system-test orga- 
nization looks at the overall system. To provide a benchmark for 
system quality, regular stress tests, or stability runs, are performed. 
During the development phase, a stability run is performed on every 
new load. These runs measure the performance of the system and 
provide data to analyze the change in performance over time. 

Stability runs are usually 24-hour sessions in a system laboratory. 
During the session, the system is operated as if it were a live-traffic 
telephone office. Routine user and maintenance activities are performed 
and a heavy call load is generated. Since many activities such as traffic 
reports and routine maintenance are automatically run on a daily 
basis, a 24-hour period allows all such regularly scheduled activities to 
take place. The effect of these regular activities on the system 
performance is observed and analyzed. Towards the end of the devel- 
opment period, extended (up to a week long) stability runs are used 
to check for subtle problems whose symptoms may take a longer time 
to surface. Longer stability runs also incorporate typical telephone- 
office-acceptance tests (see Section 5.5) such as the half-office test and 
the integrated-volume test. 

During all stability runs, the system is carefully monitored for any 
abnormal behavior. All potential problems are logged and investigated. 
The performance of the system is quantified by several metrics, 
including calls successfully processed per hour, hardware interrupts, 
software-detected audits and asserts, initializations, and printer output. 
An overall index is defined by using a weighted average of the 
individual metrics. For each metric, acceptable thresholds are defined. 
As thresholds are attained, the criteria are tightened to force continued 
effort to a higher level of quality. For example, once a phone call 
completion rate of 99.99 percent is attained, the threshold rate may 
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Fig. 4—Stability run index. 


be increased to 99.999 percent. The system must meet an acceptable 
level of quality before it is released for general use. 

The high level of quality is attained through continual, close 
cooperation between developers and testers. Problems uncovered during 
stability runs are investigated and resolved by developers who staff 
stability run teams. Each team has a speciality area, such as achieving 
high call-completion rates or decreasing the number of software audit- 
error reports. The teams directly support the stability runs during the 
last several months of the development cycle when generic quality is 
rapidly improving. Figure 4 shows the trend for a typical index. 


4.5 Test tools 


Many tools have been developed to increase testing efficiency and 
productivity. Tools used during system testing include 

1. Symbolic debuggers that provide ways to do traces, dumps, 
conditional matches, and other utilities on C language programs. 

2. A call generator that generates Plain Old Telephone Service 
(POTS) calls at specified traffic levels over standard line connections. 

3. An automatic call simulator that can be programmed to generate 
traffic loads with specified combinations of POTS and more complex 
call types on both lines and trunks. 
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4, Load-generation tools that simulate high call loads on the 5ESS 
switch to stress the system beyond limits available through other load- 
generation tools. 

5. The switching system automated test set, which performs switch- 
ing, signaling, and transmission tests under traffic conditions. 

6. The automated craft-message interface, which provides automated 
message input and detailed output analysis for automating user com- 
mands and analyzing system response. 


V. FIRST-OFFICE APPLICATIONS 


As a standard practice, major new releases of 5ESS system software 
and major new hardware units are introduced after a FOA verification. 
FOA verification is under AT&T Bell Laboratories control, and its 
primary purpose is to test the new hardware and software by operating 
the 5ESS system in a field environment. Consequently, most FOA 
tests use standard input messages and avoid the use of special utilities 
or other methods of intervention. 

The FOA-verification stage follows system testing, but the two 
overlap. As new software loads are generated, their performance, as 
measured in the FOA, helps confirm the observations made by system 
testers. 

FOA verification also gives the customer a chance to get hands-on 
training in the new features. In addition, the customer is assured by 
direct involvement that the office is ready for service. One of the main 
benefits to the supplier is an early opportunity to verify product 
performance in an actual operating environment and in a system 
configuration that is generally larger and more complex than a system 
laboratory. 


5.1 FOA selection 


FOA sites are selected to meet the service needs of certain offices 
while matching generic program availability dates. New offices that 
appear to be candidates are analyzed with respect to new features, 
schedule flexibility, and customer preference for FOA treatment. In 
some cases, a strong desire by some customers to obtain the use of 
new capabilities as soon as possible influences FOA schedules. In other 
cases, feature availability is the determining factor. 


5.2 Preparation and planning 


FOAs are chosen so all the major new features developed for each 
generic are verified. In many cases, several FOAs are needed to verify 
all features. For each selected FOA, an office verification schedule is 
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Fig. 5—Typical FOA schedule. 


generated. This schedule includes dates for the normal AT&T Network 
Systems installation activities, FOA verification, and introduction of 
new software loads. A sample schedule is shown in Fig. 5. Before the 
5ESS system arrives, early planning addresses several topics. The 
variables considered during early planning include the schedule, the 
features needed by the customer, office size, and the network intercon- 
nection plan. Before system delivery, space is allocated and provisions 
are made for installing power plant, cable racks, and making other 
building-support-structure changes. Cutover and transition committees 
are established, and they coordinate all of the activities associated 
with placing the new system into service. 


5.3 Installation interval 


The first parts of the 5ESS system delivered to the telephone office 
are the AM, Communications Module (CM), and at least two SMs. 
Nearly all intramodule cabling is done at the factory and all units are 
tested before they are shipped. This helps reduce installation time. 
After the modules are in place, power cabling and intermodule cabling 
are connected. Nearly all interframe cables for the 5ESS system are 
pretested and connectorized. This saves installation time and greatly 
reduces interframe wiring at site. 

The general philosophy of the installation is to concentrate on 
powering up the core of the switch (AM and CM) as soon as possible. 
Because the AM and CM can be operated independently from the 
SMs, the core can be tested while the SMs are still being installed. 
The installation force is split so that some testers are devoted to the 
testing of the AM and CM while the others continue doing the cabling 
and powering up the SMs. Testing the AM and CM takes about three 
days. These core units are then used to test the SMs. As the SMs are 
powered up, they may be connected to the core units one at a time, or 
all at once. In large offices, where SMs may arrive in several shipments, 
the former is generally done. 
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As mentioned above, installation testing overlaps equipment instal- 
lation. Some units are being tested while others are still being installed. 
The first test on all units is power and ground verification. Next, 
hardware circuitry is tested, much of it concurrently. Testing proceeds 
in the following sequence: AM, CM, SM control units, and finally, SM 
peripheral units. 

Hardware is tested using diagnostic programs that are part of the 
system software. A graphic status display of each hardware unit can be 
requested on the Master Control Center (MCC) video terminal. The 
display includes a menu of commands, including diagnostics, that can 
be performed on the specified unit. Installation testing starts with 
diagnosis of individual units, and proceeds to subsystems and their 
interfaces with each other. Finally, subsystem operation with the 
generic program and ODD is tested. 

Call-processing capabilities are tested next by applying a simulated 
call load to the system, with load boxes that simulate subscribers. A 
typical load box can simulate up to 64 telephone calls at one time and 
generates 15,000 calls per hour. 


5.4 Verification and software introduction 


In major FOAs, test and verification generally spans the next six 
weeks. Feature verification is planned to mesh with the same sequence 
established by system test. During the verification interval, the instal- 
lation teams continue to do office maintenance, apply hardware changes, 
and complete installation testing. At the end of the verification 
interval, installation testing continues with acceptance tests. 

During the verification interval, new software loads are introduced 
that contain corrections to problems discovered during system testing. 
New loads are usually introduced at the beginning of the verification 
interval and as often as weekly afterwards. Occasionally, new software 
loads that consolidate important corrections may be introduced after 
turnover so the corrections can be demonstrated to the customer 
before placing the system into service. 


5.4.1 FOA and feature verification 


The verification performed in the FOA includes verifying specific 
new feature operation; verifying the characteristics of the new software, 
hardware, and supporting installation; and overseeing customer-accep- 
tance testing. For each FOA site, a list of required and desirable 
features is created by the customer. FOA-verification tests are designed 
for each feature. The features that will not be activated in a particular 
FOA may be temporarily activated or verified in another FOA. 

Using previous experience to determine typical test-execution rates, 
the FOA-verification interval is scheduled for the new features. Feature 
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verification is generally scheduled for 16 hours a day, while office 
installation and maintenance activities are scheduled for the rest of 
the day. 

Test scripts are generated for each set of features. These are applied 
in the FOA, and records are kept on which tests pass and which fail. 
If a failing test reveals a problem, an IMR is generated and referred 
to a development organization. When fixes are delivered in subsequent 
loads, the failing tests are rerun to assure the problem is corrected. 


5.4.2 Generic verification 


In addition to feature-specific verification, the new software release 
is checked for overall performance by executing a set of regression 
tests. Performance is verified through weekly stability runs that 
complement those done by system testers in the system laboratories. 
The FOA-stability runs help identify configuration and office-database- 
dependent problems. The results of the stability runs are analyzed 
with the help of special programs in support computers. While FOA 
testers continue with their verification tests, members of a special 
analysis group work with developers to resolve the problems detected 
by the stability run analysis. 

A library of all FOA test scripts is maintained. A set of regression 
tests is selected from the library to assure that features provided in 
previous generics continue to function properly in the current generic. 
In selected FOAs, special performance tests are scheduled. For example, 
in one FOA, high traffic was generated by additional load boxes so 
that traffic-handling capacity could be verified. There are also special 
tests that verify compatibility with the trunk interfaces to connecting 
offices in the network and with line interfaces to station sets, coin 
telephones, PBXs, key, equipment, and range extenders. 


5.5 Acceptance tests 


At the end of the installation interval, tests are run on the switching 
system to demonstrate stability and performance to the telephone 
company. Throughout the tests, artificial traffic is applied to the 
system so that any changes in call-completion rates will indicate 
problems. Specific thresholds are designated for alarms, maintenance 
interrupts, and software errors during the tests. The specific tests 
performed are the half-office test, the heat test, and the integrated- 
volume test. 

In the half-office test, the ability of the system to operate with only 
half of the duplicated equipment available is established. In this test, 
one side of all duplicated controllers is powered down for one hour, 
powered up, and diagnosed. The process then is repeated on the other 
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side. The test takes place with a call load running, and demonstrates 
that call processing is not affected. 

The optional heat test demonstrates the system’s ability to operate 
under high-temperature conditions, such as air conditioning failure. In 
the test, a plastic tent is constructed around the switching system and 
the temperature is raised to 118 degrees Fahrenheit. The switch 
operates for four hours under these conditions while being monitored 
for correct handling of the applied call load. 

The integrated-volume test demonstrates the system stability and 
call-processing capabilities over a continuous 24-hour period under 
conditions that simulate a typical day. Again, call-completion statistics 
and other system measurements are used to help verify performance. 

Once installation is completed and all acceptance tests are successfully 
executed, principal use of the system is turned over to telephone 
company personnel so they can conduct special tests to verify that 
each trunk and line operates properly and that office data are correct. 


5.6 Metrics 


The main FOA-verification metrics used fall into the following 
categories: 

© Verification progress versus schedule 

© Verification-test pass rate 

e System quality and stability metrics. 

The combined results of these metrics are used to help determine 
that the new generic programs are ready for service and to manage 
the priority items leading to the introduction of the new generic 
program. 


VI. EARLY OFFICE INSTALLATION AND EXPERIENCE 


Installation of 5ESS systems has occurred according to the curve in 
Fig. 1. The first four systems were single-SM systems. Two additional 
single-SM systems have been added and one of the original systems 
has been converted to an RSM served by a multiple SM host. The 
rest of the installations have been multiple SM systems. As of 
November 1984, installed 5ESS systems contain from 1 to 30 SMs. 
Plans exist for offices having over 60 SMs to be installed within the 
next year. 

The first 5ESS system RSM was placed in service in April 1984; 
others will be installed according to the curve in Fig. 6. RSMs are 
currently connected to their hosts, using conventional T1 facilities, 
and T1 over fiber-optic systems as umbilical links. An optically 
remoted switching module is also in service. This configuration uses a 
direct fiber-optic link from the 5ESS system host CM to the RSM. 
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Fig. 6—Remote switching modules in service. 


Additional facts about 5ESS system capacity and installation are 
given in Table III. 


6.1 Customer support 


AT&T provides extensive support for the owners and operators of 
the 5ESS systems. Problems and requests for assistance are sent first 
to a Regional Technical Assistance Center (RTAC), then to a centralized 
Product Evaluation Control Center (PECC), and finally to AT&T Bell 
Laboratories. Generally, AT&T Bell Laboratories receives only those 
problems and requests that require design changes or corrections. 

Customer support facilities include specialized equipment that allows 
logging output from systems to help problem analysis, and portable, 
noninterfering field-test sets to help find any problems that cannot be 
reproduced in system laboratories. A large diagnostics center at the 


Table III—System dimensions 
System Capacity Maximum Observed in 
(1985) Service (11/84) 
Number of SMs 192 30 
Number of lines 100,000 27,000 
Busy-hour calls* 300,000 80,000 


* Assumes normal maintenance activities and feature use. 
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Fig. 7—Unplanned initializations (six-month rolling average). 


AT&T Network Systems division in Lisle, Illinois, is available so 
offices requesting assistance can obtain advice from system experts, 
and can have their system output displayed for use by the experts. 


6.2 Performance measurement 


Many different performance measurements are used to evaluate 
5ESS system performance. Measurements of system initializations 
traditionally have been widely followed. For the 5ESS system, initial- 
izations can occur with varying levels of impact. Most initializations 
are effectively confined by the system architecture to a single SM, and 
most do not affect stable calls. Higher-level initializations are available 
for recovering from more severe problems. Calls in the talking state 
are generally not affected even by these higher-level initializations. 
Figure 7 shows the number of unplanned initialization incidents per 
office per month. Figure 8 shows the trend for SM_ initialization 
incidents per module per month. Other system performance data that 
can be used to forecast potential trouble include measurements of 
audits, interrupts, software-check failures, and alarms. 

The reliability of the 5ESS system hardware is also tracked by 
plotting the actual circuit pack replacement rate against the expected 
replacement rate. The expected replacement rate is calculated at one 
circuit pack per month per thousand lines. The number of packs 
returned to the factory for repair is then compared to this value. A 
plot of the overall replacement rate is shown in Fig. 9. Several Line 
Unit (LU) codes have had higher replacement rates than expected, 
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Fig. 8—Unplanned switching module initializations (six-month rolling average). 


and a series of improvements in design, manufacturing, and testing 
have been made. The AM, CM, and the SM (minus the LU) are all 
showing reliability performance that tracks expectations very closely. 
The latest improvements in the LU packs are showing favorable early 
reliability in factory yield and test data. 


6.3 Retrofit and growth 


Retrofit is the general name for the introduction of new generic 
issues and their corresponding databases into an in-service 5ESS 
system telephone office. Early retrofit methods carefully controlled 
full-system initializations. The system-initialization time associated 
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Fig. 9—Hardware replacement rate trend. 
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with these retrofits was roughly proportional to the number of SMs in 
the system. Failure of any SM to successfully initialize resulted in an 
incomplete retrofit. 

Beginning with the 5E1(2)2 generic, significant improvements were 
made to the retrofit procedure. These improvements allow the new 
generic to be off-line loaded into the out-of-service half of each SM 
without affecting service. Under control of the active generic and 
without affecting service, each SM can be preinitialized with the new 
generic to detect any database or hardware problems. The resulting 
system-initialization time is independent of office size. In addition, 
calls in the talking state are saved over the retrofit. 

Growth capability allows addition of SMs, RSMs, and units within 
them, without affecting service. Growth equipment is added and tested 
in a manner similar to new equipment; however, the growth process 
is controlled with special procedures to avoid affecting service. Early 
experience with growth procedures has been very good. A number of 
SMs and RSMs have been added to in-service 5ESS systems with 
growth procedures. 
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Vill. CONCLUSION 


The high quality and reliability of the 5ESS system depends on a 
methodology that includes a series of integration, test, and validation 
phases. The integration, system testing, and FOA-verification proce- 
dures described in this paper have been used in the development of 
several major program releases. They have played a key part in the 
successful introduction of the 5ESS system and will continue to be 
important as the system evolves. 
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The 5ESS™ switching system is a digital, time-division switching system 
that is being introduced into a multiplicity of operating environments—local, 
toll, private networks, and stand-alone applications. Many of these operating 
environments are currently dominated by analog, space-division switching 
systems. Furthermore, the 5ESS switching system is being introduced into 
environments in which there have been increasing trends toward centralization 
and mechanization of operating procedures through the use of minicomputer- 
based support systems. The 5E.SS switching system has been designed to allow 
a smooth incorporation into these mechanized operating environments, while 
still retaining features needed for stand-alone operations in less mechanized 
environments. This paper describes the operational features, both administrative 
and maintenance, of the 5ESS switching system. The emphasis is on the 
features that differ from those of earlier stored program control switching 
systems. These include features that represent enhancements over those of 
earlier systems, differences mandated by a digital, time-division technology, 
and features designed to more readily adapt to operations support systems. 


I. INTRODUCTION 


The 5ESS switching system is the first time-division, digital switching 
system AT&T has designed to serve in both local and toll offices as 
well as in private network and stand-alone applications. As such, it is 
inherently a four-wire system, and includes integrated interfaces for 
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digital-carrier-serving message trunks and Digital Loop Carrier (DLC)* 
systems. In addition, the 5ESS switching system employs a modular 
hardware and software architecture. This architecture improves the 
economics of the switching system, allows more flexibility for growth, 
and simplifies the development process to introduce new technologies 
into the switching system and add new features. The operations of the 
5ESS switching system have been designed in concert with this 
modular architecture. 

The 5ESS switching system has been designed with careful attention 
to switching system operations. Over the past several years, there has 
been an increasing trend in the telecommunications industry toward 
centralized work centers and the use of computer-based Operations 
Support Systems (OSSs) to support those centers. The 5ESS switching 
system has been designed for convenient integration into these cen- 
tralized, mechanized operating environments, while retaining the fea- 
tures needed to operate in less mechanized or manual environments. 
In earlier vintage switching systems, these OSSs typically use the 
same Teletypewriter (TTY) interface that supports the work center in 
a nonmechanized environment. The 5ESS switching system’s interfaces 
to these OSSs are designed specifically for machine-to-machine com- 
munications and use higher transmission rates and the BX.25 protocol, 
a modified subset of the CCITT X.25 protocol. 

Finally, the 5ESS switching system also includes new features and 
improvements to existing features that address the operations of the 
switching system. These features are designed to take advantage of 
the new capabilities and economies that improved technology has 
made possible. These enhancements include improved craft interfaces 
and the integration of capabilities that had previously been performed 
by external equipment (e.g., line and trunk test capabilities) into the 
switching system. 

This article is organized into three major functional areas of 
operations: planning and engineering, administration, and maintenance. 
Within each of the functional categories, the major operational differ- 
ences and improvements over previous systems are discussed. 


Ii. PLANNING AND ENGINEERING 
2.1 Planning 


Two aspects of the 5ESS switching system have a major effect on 
planning for applications for the switching system: the digital switching 
network used by the system, and the modular architecture of the 
system, including a Remote Switching Module (RSM). 


* Acronyms and abbreviations used in the text are defined at the back of the Journal. 
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A digital switching system, such as the 5ESS switching system, has 
economic advantages when interfacing with digital facilities. Thus, 
having a large proportion of digital facilities in an area stimulates the 
introduction of digital switching systems. Digital switching systems 
then in turn serve to increase the movement to digital facilities. This 
mutually stimulating effect is referred to as digital synergy. Digital 
synergy applies to both digital interoffice facilities and DLC systems. 
The 5ESS switching system’s architecture includes an integrated 
interface for Tl-carrier message trunks and RSM umbilicals, the 
Digital Line Trunk Unit (DLTU), and an integrated interface for 
SLC® 96 carrier systems, the Digital Carrier Line Unit (DCLU). These 
integrated interfaces eliminate the need for terminal equipment in the 
central office and couple the planning of digital interoffice facilities 
and DLC systems with switching system planning. 

The modular architecture of the 5ESS switching system increases 
the range of applications for which the 5ESS switching system is 
attractive. This architecture includes distributed processing so that as 
the termination capacity is increased, the call-processing capacity is 
also increased by adding Switching Modules (SMs). This enables the 
5ESS switching system to grow smoothly and economically from 
small-capacity configurations to large-capacity configurations. Having 
the same switching system in all applications simplifies operations in 
a telephone company. The 5ESS switching system’s design enables it 
to host a single-module or multimodule RSM. This RSM is an 
enhanced version of the standard SM that has been modified to 
provide stand-alone switching in the event it is cut off or isolated from 
the host. RSMs interface with their host using T1 carrier. The RSM 
is designed to make Stored Program Control (SPC) switching econom- 
ical for more applications. 

A “hot slide-in” procedure has been developed for the 5ESS switching 
system. With this procedure, the 5ESS switching system is installed 
and cut into service while housed in a temporary shelter. After the old 
switching equipment is removed, the in-service 5ESS switching system 
is put in its place. This procedure reduces costs for offices that would 
otherwise require a building expansion. 


2.2 Engineering 


The 5ESS switching system takes advantage of mechanized traffic 
data collection and processing systems (see Section III), which make 
it feasible to use a large amount of data to engineer an office. Most 
older SPC systems use Average Busy Season (ABS), Time-Consistent 
Busy Hour (TCBH) engineering methods. These methods require 
studies to determine the busy hour, and then base their engineering 
on data gathered during this hour. Because most traffic-sensitive 
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equipment must provide good service when peak loads occur, regardless 
of the hour in which they occur, ABS TCBH methods based on 1 
hour of data per day require conservative engineering. The 5ESS 
switching system uses procedures in which data are collected 24 hours 
a day, and Once A Month (OAM) peak loads are calculated from these 
data. The 5ESS switching system then may be engineered to render 
good service based on either TCBH loads (ABS or high day) or 
OAM loads. 

The 5ESS switching system’s engineering (for both stand-alone 
5ESS switching system and RSM applications) is strongly influenced 
by the modular architecture of the system. In general, the switching 
system is engineered to determine the necessary quantities of the 
lowest-level units. The quantities of these units then determine the 
necessary quantities of the next higher level unit and so on. More 
specifically, the number and type of terminations appearing on the 
switching system in conjunction with their traffic characteristics are 
used to determine the number of SM subunits (e.g., line units and 
trunk units) that are required. The time-slot and call-capacity require- 
ments of these subunits then determine the number of SMs required. 
Finally, the number of SMs determines the equipage of the Commu- 
nications Module (CM), which is composed of a Time-Multiplexed 
Switch (TMS) and a Message Switch (MS). This process is mechanized 
in the 5ESS Switch Digital Ordering and Planning System (5EDOPS). 

The CM equipment used to interconnect SMs and handle messages 
between SMs and the Administrative Module (AM) is designed to 
provide full access. This design eliminates the need for CM traffic 
engineering. 


Ill. ADMINISTRATION 


Administration of the 5ESS switching system is concerned with 
ensuring objective service levels at optimum cost. It involves provi- 
sioning and assignment, data administration, capacity and equipment 
management, and resolving traffic-related service problems. 


3.1 Provisioning and assignment 


The 5ESS switching system incorporates several features intended 
to enhance the provisioning and assignment process. These features 
include the structure of the database, the switching system’s craft 
interface for accessing the database, and the interface to the Remote 
Memory Administration System (RMAS). In addition, the integrated 
digital interfaces simplify the provisioning and assignment process for 
services provided off these facilities. 

The 5ESS switching system includes a database management system 
that supports a relational database structure. This provides the users, 
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Fig. 1—A recent change view. 


(the users may be either operating company personnel or other 5ESS 
switching system software) with a logically structured database tailored 
to their needs, and enables the users to ignore the physical structure 
of the database. In the 5ESS switching system, call-processing software 
accesses the database at a level, called the base relation level, in which 
the data are organized according to needs of this software. The craft 
interface is at the view level, which is created through logical operations 
on the base relations. Views have been designed to correspond to 
operating company work functions (e.g., add a new line) so that for 
each function, the necessary information can be obtained by accessing 
the appropriate views of the database. 

The 5ESS switching system includes its own craft interfaces to the 
switching system database and an interface to RMAS. Both of these 
interfaces are at the view level. The 5ESS switching system’s interface 
is similar in format and uses much of the same software as that used 
in the office data assembly process to initialize the database of a new 
office. The 5ESS switching system has a menu selection routine from 
which views, the groupings of data at the view level, are accessed. The 
views of the database are presented in a screen format complete with 
navigational capabilities and help and error messages. Figure 1 is an 
example of a view. Database access using the view interface is available 
on site and remotely via Recent Change (RC) terminal(s). The database 
can also be accessed over the maintenance channel in a manner 
suitable for logging by the Switching Control Center (SCC) minicom- 
puter. The 5ESS switching system also has a 2400-baud, BX.25 link . 
to RMAS. The RMAS interface is similar to that of the 5ESS 
switching system. In addition, RMAS provides the 5ESS switching 
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system with enhanced data administration capabilities and provisioning 
features. These features include pending and history files to manage 
the entry of database changes into the switching system. Both the 
5ESS switching system and RMAS can print the switching system’s 
data in tabular format so that paper versions of the office records may 
be maintained and updated. 

Integrated digital interfaces simplify the provisioning process for 
T1-carrier message trunks and DLC systems. With integrated interfaces, 
there is no central office terminal equipment. Thus, there are no 
central office line assignments to be made, and the number of distrib- 
uting frame cross-connects is greatly reduced. Combined with remote 
software provisioning, this gives the capability with the 5E.SS switching 
system to add and modify services on these integrated interfaces 
without requiring a central office visit. 

Assignment for the RSM is accomplished via the host 5ESS 
switching system. This enables the RSM to take advantage of the 
database management features incorporated into the host 5ESS 
switching system and share the same craft interfaces. Only the 
distributing frame cross-connect work must be performed at the 
RSM site. 


3.2 Data administration 


Data administration ensures the availability, adequacy, and validity 
of the collected traffic data. Traditional traffic reports are available in 
human readable format over the Network Administration I/O channel. 
The 5ESS switching system also provides an interface to the Engi- 
neering and Administrative Data Acquisition System (EADAS). EADAS 
provides an interface to the Total Network Data Systems (TNDS). 

The administrative interface for the RSM is through the host 5ESS 
switching system. Thus, all the administrative features of the 5ESS 
switching system are also applicable to the RSM. 

The EADAS interface uses the BX.25 protocol and is 2400 baud. 
EADAS polls the 5ESS switching system for a half-hourly, hourly, 
and 24-hour data collection schedules. Data validation is performed by 
EADAS. For the 5ESS switching system, EADAS creates C, E, H, 
and P schedules from the half-hourly data and passes them to the 
downstream TNDSs for additional processing. The C schedule includes 
trunking and customer usage data, the E schedule contains the extreme 
value data for usage-sensitive equipment, the H schedule includes 
hourly data and half-hourly data for special studies, and the P schedule 
has the processor capacity estimation data. The downstream T'NDSs 
have been expanded to support the 5ESS switching system as a new 
switching system type. These systems perform functions for network 
management, load balancing, forecasting switching system and facility 
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growth, and indexing system performance. (See Refs. 1 through 3 for 
additional information.) 


3.3 Capacity and equipment management 


A primary function of switch administration is to ensure an efficient 
utilization of equipment. The goal is to maximize equipment utilization 
and minimize the quantity of equipment needed to provide the desired 
grade of service. Capacity management ensures that sufficient equipment 
is available and load balancing ensures that it is efficiently utilized. 

The modular architecture and use of distributed processing in the 
5ESS switching system allows both call-processing and network capacity 
to be added. This is done by adding SMs to a system. Capacity 
estimation procedures using extreme value methods have been developed 
to determine and anticipate overload conditions. For the 5ESS switching 
system, these procedures are expanded because of the distributed 
processing scheme, which requires multiple processors to be monitored. 
While adding SMs increases the call-processing and network capacity, 
SM subunits are added to provide additional terminations. 

Since the design of the 5ESS switch network is such that blockage 
can only occur in the line concentrator stage of the network, load 
balancing is only required to assure that individual concentrators are 
not overloaded. This is achieved by assigning lines based on their class 
of service. Trunks may be distributed to optimize reliability without 
regard to load balance. The 5ESS switching system has no space- 
division junctors, hence junctor rearrangements are eliminated. 


3.4 Trouble resolution 


The switch administrator is responsible for the resolution of traffic- 
related service problems. The 5ESS switching system includes an 
I/O channel—the NAC channel—for this purpose. This channel is a 
virtual channel over the BX.25 interface to the No. 2 Switching 
Control Center System (SCCS). This enables the administrator to 
take advantage of the SCCS minicomputer capabilities (e.g., logging, 
browsing, filtering, and alarming of messages). Over this channel the 
administrator has access to the switching system’s database, to office 
status and control information, and traffic information. For dealing 
with traffic overload conditions, the 5ESS switching system includes 
controls to reduce the load offered to the switching system and is 
designed to dynamically alter the allocations of system real time in 
response to changes in load. The essential service protection feature 
may be activated or inhibited to reduce the number of recognized 
requests for service via this channel. Network management controls 
are available to control the flow of traffic into and out of a 5ESS 
switching system office over trunks. These controls may be activated 
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“on-site” [at the Master Control Center (MCC) or SCC] or via 
EADAS/NM (network management). 


IV. MAINTENANCE 


The maintenance features designed into the 5ESS switching system 
make it well suited for both highly mechanized environments and 
other less mechanized environments. Its inherent flexibility allows it 
to work in a variety of operational environments and configurations. 
The maintenance interface is a user-friendly one that, by the use of 
video displays and easy-to-use menus, guides the craft through the 
control operations used to maintain the system. 


4.1 Maintenance objectives 


The overall reliability and availability objectives of the 5ESS switch- 
ing system are detailed in Ref. 4. From a maintenance perspective, 
these objectives distill into the following points: First, the 5ESS 
switching system should perform as much of the maintenance as it 
can without the need for craft intervention. Whenever a trouble 
condition occurs, the crafts people should be notified of it, along with 
the criticality of the event. When the crafts people must take corrective 
action, it should be easy to identify and isolate the trouble quickly and 
unambiguously, and the repair should be quickly effected. Lastly, 
except for pack replacement and other “hands-on” repair, all mainte- 
nance control and display capabilities should be available on-site and 
at the remote SCC. 


4.2 Maintenance capabilities 
4.2.1 General 


The 5ESS switching system has a full complement of audits, 
interrupts, purges, and diagnostics. Details of these may be found in 
Ref. 5. 


4.2.2 Craft interface 


The craft interface for system maintenance at the central office is 
the MCC. Figure 2 shows the most frequently used parts of the craft 
interface. Instead of having a custom, hard-wired key and lamp panel 
for each office, as other SPC systems have, the maintenance interface 
uses a video display and keyboard unit similar to the one discussed in 
Ref. 6. The displays are software controlled and are easily changed to 
track the particular 5ESS switching system’s configuration. The upper 
part of the screen always displays a summary of the critical indicators, 
including the alarm-level indications CRITICAL, MAJOR, and MINOR, 
and the “type” indicators such as BLDG/PWR and MSGS/TMS, which 
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Fig. 2—Parts of a master control center. 


indicate the trouble source. On monochromatic terminals, these indi- 
cators would be displayed in reverse video or blink to indicate the type 
and the severity of the trouble. For the optional color terminals, 
changing status would be shown by a change in color. 

Below this area, the crafts people can select different “pages” to be 
displayed in order to perform the control and display functions similar 
to other SPC systems. The pages consist of an ordered list (a menu) 
of control and/or display functions that can be selected by entering a 
3- or 4-digit number followed by an execute character. Usually accom- 
panying this menu is a graphical representation of the status and 
interconnection of equipment. There are separate pages for different 
types of equipment and for different levels of detail. 

As in other SPC systems, the 5ESS switching system has a “belt- 
line” function that allows craft at the switching frames to interact 
with the switching system. By means of a portable TTY, the crafts 
people can input messages and receive appropriate output and system 
status messages. 


4.2.3 Diagnostics 


Flexibility and power are the hallmarks of the 5ESS switching 
system’s diagnostics. An entire equipment unit, a particular subunit, 
or all the subunits in a particular community can be diagnosed. 
Complete tests, a range of test phases, or particular phases may be 
run. While most requests can be initiated automatically, all requests 
can be initiated manually. To aid in troubleshooting, interactive 
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features such as stepping, looping, and pausing are provided. Manual 
requests can be entered from the maintenance terminal by either 
menu selection or message input. 

Diagnostic results can be sent to the maintenance terminal and the 
printer. Unlike other SPC systems, which print trouble numbers that 
must be decoded by referencing a Trouble-Locating Manual (TLM), 
the 5ESS switching system can be requested to print a list of suspected 
faulty circuit packs. This Trouble Location Procedure (TLP) option 
provides an ordered list of packs, including their locations, which 
simplifies the repair procedure. It is expected that 90 percent of all 
faults can be cleared by replacing one or more of the boards listed 
with nearly half of the faults cleared by the first pack on the list. 


4.2.4 Emergency action interface 


In the unlikely event that the 5ESS switching system cannot recover 
from a catastrophic failure, the Emergency Action Interface (EAI) 
provides manual control and basic status information. The EAI circuit 
can access the 5ESS switching system regardless of system configuration 
or software sanity. Firmware in the EAI controls a display that allows 
the crafts people to force system configurations, to inhibit error sources 
and sanity checks, and to initialize the system. In the event of a 
complete system outage, the EAI provides a gross diagnostic capability 
in the form of processor recovery messages. The EAI page is displayed 
on the same terminal as other maintenance displays, and is available 
at both the central office maintenance terminal and remotely at 
the SCC. 


4.2.5 Initializations 


Initializations in the 5ESS switching system are very comprehensive. 
The 5ESS switching system supports a variety of initialization levels 
from a single process purge to a full initialization and memory 
reload.’ The distributed architecture of the 5ESS switching system 
permits initializations of separate units of the switching system, often 
with little effect on the other units. For example, one SM may be 
initialized without interfering with call processing in other modules. 
Likewise, some levels of AM initialization have little effect on the 
periphery. If more drastic actions are required, the entire system may 
be initialized. 


4.2.6 Switching Control Center System interface 


The Switching Control Center System (SCCS) provides the hardware 
and software to control, administer, and maintain SPC systems from 
a remote centralized location. This is accomplished through a combi- 
nation of audible and visual alarms, status panels, and video displays 
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for status control. The SCCS also provides analysis and computational 
tools, office records, and interfaces to other operations systems and 
centers. (See Refs. 7 and 8 for more thorough discussions of the SCC.) 

The 5ESS switching system is fully compatible with the SCCS. All 
SCCS functions that can be performed on other SPC systems can be 
performed on the 5ESS switching system. All maintenance control 
center functions are remoted to the SCC, including the emergency 
action interface page. The displays at the MCC and SCC are identical, 
which improves craft communications between the central office. and 
the SCC. In addition, the 5ESS switching system shares a common, 
standard interface design with other AT&T 3B computer processor- 
based systems.® 

Communication between the 5ESS switching system and the SCCS 
is via a duplicated data link using the BX.25 protocol. BX.25 is a 
packet-switching protocol for error-free data communications, which 
allows for the multiplexing of separate “virtual channels” on a single 
facility. Thus, savings are realized on facility and terminal costs while 
promoting a standardized interface to future packet-switched networks. 

All alarms, control and display information, input and output 
messages, and other.maintenance data are sent on separate, virtual 
channels over the same BX.25 link. This is in contrast to other SPC 
systems, where TTY and telemetry information are sent over separate, 
nonduplicated links. In the case of a link outage, BX.25 provides for 
an automatic switch to the standby link. Therefore, the interface to 
the SCCS is fully duplicated and full functionality is maintained 
during any single link failure. 


4.3 RSM maintenance 


The RSM in the 5ESS switching system’s architecture is an SM 
designed to be used in a variety of remote applications. As discussed 
in Section 2.1, to minimize the impact of host office troubles and 
facility failures, when the RSM cannot communicate with the host, 
its stand-alone mode will provide basic telephone service within the 
customer community. While in this mode, emergency lines will also 
be provided to assure access to emergency service. 

While the maintenance of the RSM has been designed to be virtually 
identical to that of the host SM, the remoteness of the RSM implies 
some differences. Trouble will be sectionalized sufficiently to ensure 
that craft will be dispatched only when necessary, and that minimum 
spare parts will be taken to the remote site. 

Most RSM maintenance will be controlled from the SCC, where 
testing will determine if and when a dispatch is necessary. Most tasks 
requiring craft. at the RSM site will be accomplished by one crafts 
person, using a portable TTY. This TTY will have access to the SCCS 
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via a secure dial-back arrangement, or to the host office as an extension 
of the belt line. Optionally, a remote MCC terminal may be provided 
at the RSM site. When necessary, assistance can be provided by a 
controller or analyzer at the SCC, or by another crafts person at the 
host office. 

The crafts people at the RSM will have a simple status panel that 
will show RSM alarm information and an indicator that will show 
when the RSM is in the stand-alone mode. 


4.4 Line and trunk testing 


The 5ESS switching system is designed to fit into the existing 
environment for line and trunk testing, and also to support improved 
interfaces for these functions. This includes providing testing capabil- 
ities within the 5ESS switching system and supporting interfaces to 
remote test systems such as the Centralized Automatic Reporting on 
Trunks (CAROT) and Mechanized Loop Testing (MLT) systems. 
Thus, to support line and trunk testing, the 5ESS switching system 
provides metallic access, built-in test capabilities, and craft interfaces 
(both local and remote). 

The 5ESS switching system includes a line and trunk testing craft 
interface called the Trunk Line Work Station (TLWS). This interface 
shares the same physical equipment as the MCC for switching systems 
maintenance and accepts two forms of input: menu mode and TTY 
messages. From this interface administrative actions such as changing 
the state of the line or trunk, actual line and trunk tests, and 
miscellaneous functions such as monitor-only connections may be 
performed. For large offices that require large volumes of testing, as 
many as six supplementary 'TLWSs may be equipped. 

In addition to the manual tests that may be performed at the 
TLWS, the 5ESS switching system performs automatic tests. For 
lines, these include standard per-call tests and Automatic Line Insu- 
lation Testing (ALIT), which includes tests of integrated SLC 96 
system lines. The ALIT function is performed by equipment integrated 
into the 5ESS switching system. Loop segregation tests are run on a 
periodic basis to differentiate between loaded and nonloaded loops. 
These tests ensure that the system provides the proper balance 
network for echo control during calls. For trunks, automatic outgoing 
transmission and operational test calls are provided. 

For line- and trunk-testing OSSs, the 5ESS switching system, in 
addition to providing metallic access for the conventional testing 
interface, is designed to support more sophisticated interfaces and 
eliminate the need for external test equipment. This permits external 
testing systems to share these capabilities. The 5ESS switching system 
includes equipment called the Transmission Test Facility (TTF) and 
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the Directly Connected Test Unit (DCTU) that, along with system 
software, perform test functions that external equipment such as the 
Remote Trunk Test Unit (RTTU) and Loop Testing System (LTS) 
provided for other switching systems. The TTF implements the loop 
segregation tests, the various transmission test lines, and the Remote 
Office Test Line (ROTL) functions. The DCTU provides dc and 
subaudio measurement capabilities. Thus, as well as providing for 
remote testing in the same manner as other switching systems, the 
5ESS switching system anticipates an environment where remote test 
systems (e.g., CAROT and MLT) request a test, and the switching 
system performs the test and delivers the results. In this environment, 
the test systems will communicate with the 5ESS switching system in 
a manner similar to RMAS and EADAS, using BX.25 protocol. 

Finally, in addition to performing tests for remote testing systems, 
the DCTU also eliminates the need for much of the portable test 
equipment at the central office. If the loops at the RSM are to be 
tested, they must also be equipped with their own DCTU. 


V. SUMMARY 


The 5ESS switching system has been designed with an operational 
flexibility that allows it to work in a variety of operational configurations. 
In particular, the 5ESS switching system has been designed with a set 
of enhanced interfaces that accommodate its integration into highly 
centralized and mechanized operating environments, as well as features 
that provide for operations in offices that are not as highly mechanized. 
Thus, the 5ESS switching system includes a wide range of opera- 
tional features and enhancements for a wide variety of operational 
environments. 
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This paper describes factory system testing for the 5ESS™ switch. Factory 
system testing is performed using standard maintenance and diagnostic features 
of the 5ESS switch. The design of the factory system testing process is based 
on the distributed architecture of the 5ESS switch and is described in this 
paper. The system-level requirements that each 5ESS switch must meet before 
shipment to the field are also discussed. — 


I. INTRODUCTION 


The process of testing hardware for the 5ESS switch involves several 
stages, beginning with circuit-pack testing in the factory and progressing 
to final system acceptance testing in the field. The objective of this 
process is to give the customer a high-quality system that meets the 
design requirements of the 5ESS switch. This paper describes Factory 
System Testing (FST)? of the 5ESS switch, the final stage of factory 
testing that ensures that each 5ESS switch meets stringent requirements 
before being shipped to the field. 

The FST process for the 5ESS switch is designed to be both 
effective and efficient, with the specific objective of resolving system- 
level hardware problems in the factory rather than in the field. This 
objective is achieved by performing FST with the standard generic 
program using standard system diagnostics. The required efficiency 
has been achieved by using the distributed architecture of the 5ESS 
switch in the design of the FST process. 
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Copyright © 1985 AT&T. Photo reproduction for noncommercial use is permitted 
without payment of royalty provided that each reproduction is done without alteration 
and that the Journal reference and copyright notice are included on the first page. The 
title and abstract, but no other portions, of this paper may be copied or distributed 
royalty free by computer-based and other information-service systems without further 
permission. Permission to reproduce or republish any other portion of this paper must 
be obtained from the Editor. 


1537 


Section II of this article describes the different types of testing 
performed in the factory on the 5ESS switch. Section III presents the 
strategy that has been adopted for FST of the 5ESS switch. Features 
in the standard generic program of the 5ESS switch that are particularly 
useful in performing FST are discussed in Section IV. Sections V and 
VI review the activities performed during FST of the 5ESS switch 
and summarize the specific test criteria that must be met. Finally, 
Section VII describes the quality-assurance program for the 5ESS 
switch as it applies to FST. 


Il. FACTORY TESTING PERFORMED ON A 5ESS SWITCH 


Testing performed in the factory for the 5E.SS switch can be divided 
into component testing, circuit-pack testing, unit testing, and system 
testing. Circuit-pack testing is performed on all plug-in elements as 
individual entities before they are inserted into units of the 5ESS 
switch. Units are composed of one or more equipment shelves that 
house the circuit packs. Depending on the function of a given unit 
within the system, testing may or may not be performed at the unit 
level before system testing. System testing makes full use of the system 
environment of the 5ESS switch to provide final check-out of the 
system. These four testing phases are described below. 


2.1 Component test 


5ESS system performance dictates the use of components that 
exhibit high levels of quality and reliability. To meet quality and 
reliability requirements, components are procured against rigid speci- 
fications that assure both incoming quality and long-term reliability. 
Exacting standards for ac and dc electrical testing, metallic-lead 
finishing, and burn-in are specified to eliminate infant mortality. 
Sample lots of components are screened to determine compliance with 
these quality standards. 


2.2 Circuit-pack test 


The 5ESS switch is composed of both analog and digital multilayered 
circuit packs, although most of the pack codes are digital. Functional 
tests for digital circuits are generated by circuit simulation.’ Further 
processing of test vectors is provided by a diagnostic retrieval algorithm? 
that converts the vector sets into the proper format required by the 
circuit-pack test sets. 

Before functional circuit-pack testing is performed, many circuit 
packs of the 5ESS switch are tested for short circuits, open circuits, 
device orientation, and device tolerance using an in-circuit test set. 
The in-circuit test set is less expensive than the functional test set 
and provides a more convenient method for detecting mechanical 


1538 TECHNICAL JOURNAL, JULY-AUGUST 1985 


faults. Repair facilities are located near each test set so that circuit- 
pack transport and handling are minimized. 

The failure rate of circuit packs in system testing is used as a 
constant monitor of the effectiveness of circuit-pack testing. The 
testing objective is to locate circuit defects at the earliest possible 
stage of manufacture so that defect repair costs are minimized. 
Emphasis on circuit-pack fault coverage enhances the system-test 
circuit-pack yield. 


2.3 Unit test 


Unit testing of subassemblies in the 5ESS switch takes on two 
forms. Unit testing was considered a necessity during the manufacturing 
start-up period of the 5ESS switch. The unit-testing capability divided 
the product into functional entities and provided a means for quickly 
isolating design and manufacturing difficulties. Experience with previous 
electronic switching system switches, however, showed that as a 
product reaches maturity, less intermediate testing is required. Early 
planning for the 5ESS switch, therefore, scheduled unit testing to be 
phased out of the manufacturing process where possible. The foremost 
goal was that the quality of the 5ESS switch would not be compromised. 
Unit testing thus existed only temporarily for Switching Module (SM) 
peripheral units such as line units (LUs) and trunk units (TUs), while 
other units and subassemblies continue to be tested at the unit level. 
All equipment of the 5ESS switch that bypasses the intermediate unit 
test is tested using system diagnostics and must meet system-level 
requirements before being shipped from the factory. 

Permanent unit-test facilities remain for system elements that are 
critical for the system-testing operations. The Switching Module 
Processor Unit (SMPU) is unit tested along with its Time-Slot 
Interchange Unit (TSIU), since these units are necessary for testing 
SM peripheral units in system test. Guaranteeing a known good 
SM controller enhances the ability to easily bring up an SM in a 
system environment. The Communications Module (CM) parts of the 
system—the Message Switch (MSGS) and Time-Multiplexed Switch 
(TMS)—as well as the AT&T 3B20D computer are all pretested before 
system testing. 

Many of the unit-test sets were derived from laboratory test sets 
used during development of the 5ESS switch. Most were minicomputer 
based with custom interfaces designed to communicate with the 
particular unit to be tested. Software for the test sets was developed 
primarily on computers running with the UNIX™ operating system 
and often included translated system diagnostics. Much of the test 
software was compiled on off-line computers and down loaded into the 
individual test-set computers. 
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2.4 Factory system test 


FST of switching equipment generates a product whose hardware 
and software have been successfully integrated. This integration and 
testing eliminates inconsistencies between physical hardware equipage 
and database hardware equipage. However, the major benefit of FST 
is its demonstration that while being exercised at full system speed, 
the equipment meets end system requirements in a nonsimulated 
environment. 

Further benefits of FST include a reduced installation interval, 
consistency between factory and installation procedures, early identi- 
fication of hardware and software problems, and greater customer 
satisfaction. These benefits are achieved because the system is truly 
operated in its native mode, i.e., under the same conditions that the 
machine will encounter in field operation, including stress conditions. 

To ensure that end requirements are met, all system testing of 
hardware is performed with the standard generic program. The equip- 
ment configuration database that describes the hardware equipage is 
derived from the Systems Equipment Engineer’s specification. Thus, 
the factory provides system verification using system-level hardware 
and software configurations while operating in an environment similar 
to that encountered in the field. 


Il. SESS SWITCH FACTORY SYSTEM TESTING STRATEGY 


Planning for FST of the 5ESS switch was based on principles of 
previous electronic switching system switches but was heavily influenced 
by the modular architecture of the 5ESS switch. The basic building 
block of the 5ESS switch is the SM. The greater part of switch 
maintenance, and hence system testing, is carried out within each SM 
through the intelligence of the SM controller. The fact that SMs are 
loosely coupled to the TMS via the fiber-optic Network Control and 
Timing (NCT) links led to a modular testing concept. Consequently, 
a dual-phase FST was proposed and implemented for the 5ESS switch. 


3.1 The SMST/MMST concept 


In the first testing phase all SMs are tested in a full-system 
configuration known as Switching Module System Test (SMST). The 
SMs under test are served by a factory-installed host complex composed 
of an Administrative Module (AM), and a CM consisting of a duplex 
MSGS and a duplex TMS. The second phase is called Multimodule 
System Test (MMST). In the MMST process the essential elements 
of each office are assembled and connected. The AM and CM are 
connected with the first two SMs (previously tested in SMST) to 
produce a working office configuration. Each MMST office receives a 
complete system test, including call-volume testing. 
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SMST provides a parallel process that can intermix and test SMs 
destined for several different telephone offices. Each SMST test 
position is assigned an SM, and up to 15 SMs can be tested simulta- 
neously with a single SMST Host System. The standard generic 
program controls the SMST complex. Therefore, an SMST complex 
is similar to a 15-SM office and provides a complete FST environment. 
Likewise, MMST is also performed using the standard generic program. 
Emphasis in MMST is placed on verifying that a base configuration 
of hardware will pass all phases of end office requirements, including 
call-volume testing, to which the remaining SMs system tested in 
SMST can easily be added in the field. 


3.2 Cost-effectiveness of SMST/MMST 


The reduction in FST costs through the SMST/MMST concept is 
achieved for several reasons, which are discussed in the following 
sections. 


3.2.1 Reductions in inventory costs 


In-process inventory costs accrue rapidly for offices during the FST 
process. Offices undergoing FST are complete except for final test 
verification. SMST provides a highly parallel operation where most 
SMs for a given office are tested at the same time. The first two SMs 
for each office are tested earlier in SMST and sent to MMST, where 
these SMs are mated with the AM and CM while the balance of the 
SMs for that office are still being tested in SMST. Thus, SMST and 
MMST taken together form parallel processes and hence a reduced 
factory interval. 


3.2.2 Reductions in unit-test costs 


SMST replaces the unit testing of SM peripheral units while 
providing end requirement tests for SMs of the 5ESS switch. The 
capital investment in unit-test facilities is saved, as well as the testers 
required to operate the test facilities. SMST derives much of its cost 
avoidance from these two areas. 


3.2.3 Floor space savings 


SMST and MMST minimize the need for factory floor space. SMST 
requires less movement and handling of 5ESS system units and 
cabinets than do the unit testing operations. In addition, SMST 
concentrates more product per square foot of floor space than does 
unit testing. MMST of a fixed-size office configuration allows instal- 
lation of standard test areas including system power, lighting, test line 
distribution, and maintenance consoles. 
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3.2.4 Minimization of redundant testing 


Unit testing eliminated by SMST consisted, in part, of tests derived 
directly from system diagnostics. The SMST application of system 
diagnostics in a system environment is the preferred method of testing. 
Although the unit test, if left intact, would generate high unit yields 
into SMST, many of the same tests would be rerun on the SMs in 
SMST. The goal for the 5ESS switch was to eliminate redundant 
testing of this sort throughout the manufacturing process. Clearly, 
SMST and MMST fulfill this goal for 5ES.S equipment and system 
testing. 


3.2.5 Diagnostic effectiveness 


The requirement is that system diagnostics detect all failures that 
occur during full operation of the 5ESS switch. Specifically, if an 
operational failure occurs during call processing, the normal system 
maintenance diagnostics should also detect the failing hardware. Both 
AT&T Bell Laboratories and AT&T Network Systems engineers 
performed detailed experiments to ensure this requirement was met. 
Obviously, the end product benefited from this work since the confidence 
in the overall diagnostic and maintenance capability of the 5ESS 
switch was increased. This effort indicates that a thoroughly diagnosed 
SM is traffic worthy on arrival in the field. 


3.3 System testing of growth SMs and remote switching modules 


Installed 5ESS switches are expanded by the addition of new SMs 
to the CM or by the attachment of Remote Switching Modules (RSMs) 
to the office. SMST easily accommodates testing of growth SMs using 
the same procedures that are followed for all other SMs. To test 
RSMs, helper SMs, consisting of an SMPU, TSIU, and Digital Line 
Trunk Unit (DLTU), are connected to an SMST host to provide 
digital trunk communication with the RSM under test. 


3.4 Sustaining SMST/MMST test objectives 


SMST and MMST represent a modular testing concept designed to 
complement both the modularity and distributed intelligence of the 
5ESS switch. Robust system diagnostics and maintenance software 
ensure complete SMST and MMST hardware testing in the factory. 
However, the factory gives considerable attention to the monitoring 
and recording of circuit-defect information. SM circuit defects found 
in MMST provide a constant check of SMST product quality and 
process reliability. An unacceptable circuit-pack yield in SMST and 
MMST results in corrective action to determine and fix the problem. 
In addition, the factory relies on its review of field problems to check 
factory processes. The factory philosophy is to correct problems at the 
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source rather than provide additional system-testing steps to screen 
defects. 

The SMST and MMST role in the overall factory-test philosophy 
for the 5ESS switch is to provide rigorous end requirement verification. 
But, since SMST and MMST also replace intermediate unit testing 
steps, this role could not be fulfilled without particular generic software 
features. These software features provide control of faulty hardware, 
efficient procedures for hardware check-out, and detailed summaries 
of the system status. A description of these generic software features 
is provided in the following section. 


IV. USES OF THE GENERIC PROGRAM OF THE 5ESS SWITCH FOR 
FACTORY SYSTEM TESTING 

FST of the 5ESS switch is performed using the standard generic 
program. The FST environment, however, is considerably different 
from that of an in-service office. The major differences are as follows: 

1. Multiple faults commonly occur both in SMST and MMST. 

2. Many simultaneous diagnostics are run in SMST. 

3. Heavy emphasis is placed on resolving hardware problems both 
in SMST and MMST. 

4, Fifteen test positions operate in parallel and communicate with 
the system in SMST. 

These special requirements for FST are handled by standard features 
available in the generic program of the 5ESS switch. 

The min-mode feature allows the system to handle multiple faults 
in both SMST and MMST. Furthermore, min-mode provides the 
5ESS switch with the capability of handling extremely infrequent but 
critical occurrences of multiple faults in the field. 

The execution of many simultaneous diagnostics in SMST is possible 
because of the diagnostic environment provided by the 5ESS switch. 
In addition, the features provided by this diagnostic environment are 
extremely useful to the installer and after cutover result in improved 
efficiencies for operating company maintenance personnel. Various 
system troubleshooting features are also available to help resolve 
hardware problems both in the factory and in the field. 

The capability to support 15 testers working in parallel during 
SMST is provided by an output message routing feature. Installers in 
the field also use this feature during the installation interval. 

The features of the 5ESS switch that are particularly useful in 
SMST and MMST are described in the following sections. 


4.1 Min-mode 


Min-mode provides a capability for factory system testing hardware 
containing multiple faults in critical units. Using SM min-mode, it is 
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possible to bring up an SM from an unknown state and test it using 
the SMST procedure specified in Section 5.4. Using AM min-mode, it 
is possible to bring up the AM and CM and test this hardware using 
the MMST procedure specified in Section 6.4. 

SM and AM min-mode are invoked separately. Entry to or exit 
from min-mode can only occur through manual action, and it results 
in a single initialization. When in min-mode, indicators are displayed 
on the Master Control Center (MCC) terminal indicating the sys- 
tem’s status. All manual requests for system action are honored in 
min-mode. 

Min-mode is the one feature of the 5ESS switch that allows the 
standard generic program to be used for FST. Although min-mode is 
used routinely during FST, it is used to a much lesser extent during 
the installation interval and is available for emergency use in cutover 
offices. 


4.2 Diagnostic environment features 


The capability to efficiently diagnose hardware of the 5ESS switch 
is important in achieving the FST cost objectives for the 5ESS 
switch. Features provided by the diagnostic environment of the 
5ESS switch are major factors in obtaining the required testing 
efficiency. These features are concurrent diagnostics in a single SM, 
the SM global diagnostic request, the diagnostic status report, and the 
diagnostic test status report. The following sections describe these 
features. 


4.2.1 Concurrent diagnostics in a single SM 


The SM concurrent diagnostic feature allows up to four diagnostics 
to run simultaneously in a single SM. Concurrent diagnostics can 
result from various combinations of automatic and manual requests. 
Automatic diagnostic requests are given higher priority than manual 
diagnostic requests to ensure quick response to fault-recovery actions. 

A diagnostic request blocking strategy is used to ensure that in a 
single SM only one diagnostic is active in each peripheral unit at a 
given time. This restriction is necessary since diagnostics cannot share 
certain resources within a peripheral unit. Furthermore, simultaneously 
diagnosing both sides of a duplicated unit in an SM is also blocked. 
When a diagnostic request is blocked, however, it is only delayed until 
the conflicting diagnostic completes execution. 


4.2.2 SM global diagnostic request 


The SM global diagnostic request allows a system tester to enter a 
single diagnostic request and diagnose an entire service group in an 
SM peripheral unit. An option is provided either to diagnose all 
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circuits unconditionally or to stop after the first failure. In some types 
of peripheral units a single global diagnostic request for a service group 
can be used instead of specifying as many as 16 individual diagnostic 
requests. The use of SM global diagnostic requests with the concurrent 
SM diagnostic feature results in significant reductions in FST intervals 
for the 5ESS switch. 


4.2.3 Diagnostic status report 


The diagnostic status report is a summary report that can be 
requested and specifies the current status of all AM, CM, or SM 
diagnostic requests. This report is particularly useful when testing an 
SM with as many as four diagnostics running at once. The diagnostic 
status report specifies for each active diagnostic request whether the 
requested diagnostic is currently queued or executing, the type of 
request (i.e., normal diagnostic, restore, test, exercise, or routine 
exercise), and whether the diagnostic was automatically or manually 
requested. 


4.2.4 Diagnostic test status report — 


The diagnostic test status report is a summary report that can be 
requested and specifies the complete diagnostic status of all diagnosable 
units and circuits in either an SM or the CM. For each diagnosable 
entity, this report specifies the status of either (1) all tests passed, (2) 
conditionally all tests passed (occurs if a helper circuit is not available 
for a diagnostic), (3) some tests failed, or (4) no test run. With this 
information it is possible to easily and accurately determine the work 
remaining to be completed in testing an SM or the CM. 


4.3 Troubleshooting features 


Troubleshooting features are provided in the generic program of the 
5ESS switch to supplement the standard system diagnostics. In the 
factory these features aid in resolving hardware problems that are 
either intermittent or involve marginal conditions. These troubleshoot- 
ing features are generic utilities, utility call trace, and the library 
supervisor. The following sections describe these features. 


4.3.1 Generic utilities 


The 5ESS switch provides generic utilities that are used for both 
software and hardware troubleshooting. These utilities provide debug- 
ging capabilities in both the CM and the SM. The generic utilities are 
used to troubleshoot certain hardware faults not identified by fault- 
recovery software and not detected by system diagnostics, but resulting 
in operational failures. They are triggered by conditional or uncondi- 
tional utility commands. 
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Fig. 1—Utility-call-trace master control center page. 


One use of the generic utilities occurs when a fault is detected by 
system diagnostics and isolated to a circuit pack but the circuit pack 
still passes all the circuit-pack tests run before system testing began. 
The utilities can be used to further analyze the failure and isolate the 
faulty component. Circuit-pack testing can then be improved to include 
additional tests. A use of the SM generic utilities with the utility call 
trace is described in the following section. 


4.3.2 Utility call trace 


Utility call trace provides the capability to identify the specific 
hardware and software configuration used in processing a call. This 
feature is used during MMST to resolve problems associated with any 
calls that fail. All hardware information associated with a call is 
displayed on an MCC page that specifies the path of the call through 
the system. Figure 1 shows an MCC page displaying a line-to-line call 
in the talking state. The dynamic data structures associated with 
controlling the call are printed on the Read-Only Printer (ROP). 

Utility call trace can be activated using either input messages or 
generic utility breakpoints. The port, circuit, or time slot used by a 
call can be specified in an input message as the trigger for utility call 
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trace. Furthermore, generic utility breakpoints can be set in the failure 
legs of either the feature control or peripheral control subsystems to 
trace a failing call without prior knowledge of the hardware to be used. 
The programmable call generator used to generate traffic during 
MMST has a feature to trap on failing calls and hold the call. This 
feature is used with utility call trace to identify specific hardware 
problems. 


4.3.3 Library supervisor 


The library supervisor controls the execution of individual client 
programs. These client programs are not a part of the standard generic 
since they are only used for special-purpose functions. Client programs 
are installed from tape on the AM’s disk and are executed and 
controlled by the library supervisor. Client programs are written in 
the C programming language and compiled using the development 
environment for the 5ESS switch. 

Library supervisor client programs can execute in different SM/AM 
environments. The possible environments are an SM client program 
running in one or more SMs; an AM client program; an SM client 
program running in one or more SMs all communicating with an AM 
client program; an SM client program running in several SMs all 
communicating with each other; and an SM client program running 
in several SMs, all communicating with each other and with an AM 
client program. Input commands are available to load, delete, start, 
and stop the execution of library supervisor client programs. An 
additional input command is available that allows the user to pass 
information to client programs. Individual client programs can generate 
output messages supplying information to the user. 

The library supervisor is used in SMST and MMST for special- 
purpose troubleshooting. For example, system diagnostics are designed 
to resolve hardware problems to the circuit-pack level. However, with 
a library supervisor client program certain failures can be analyzed to 
a more detailed level such as the device level. Since no unit testing is 
performed on SM peripheral units, library supervisor client programs 
can be especially useful in resolving any diagnostic failures that occur 
in SMST but are not detected in circuit-pack test. 


4.4 SM output message routing feature 


Multiple terminals are used by the system testers during SMST, 
where a terminal connected to the AM is provided for each of the 15 
SMST test positions. Normally the 5ESS switch routes all maintenance 
and diagnostic output messages to the MCC terminal and the ROP. 
However, a feature of the 5ESS switch allows autonomous system- 
generated messages associated with a particular SM to be routed to a 
specific terminal. With this feature, messages such as interrupts or 
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Fig. 2—Switching module system test configuration. 


reports on fault-recovery actions from a particular SM can be routed 
to the terminal at the proper SMST test position. An SM message- 
routing table is maintained by the 5ESS switch. This table can be 
dynamically altered by a system tester to control the routing of 
messages from a specific SM to a particular terminal. With this feature 
it is possible to effectively test SMs from 15 terminals during SMST. 
The following section describes the SMST process, in which many 
of the features of the 5ESS switch described in this section are used. 


V. SWITCHING MODULE SYSTEM TEST 


The purpose of SMST is to provide an efficient and effective FST 
of SMs for the 5ESS switch. The SMST process, which involves 
testing SMs with the SMST Host System, is described in this section. 


5.1 SMST configuration 


The SMST Host System consists of a factory-installed AM and CM 
connected by NCT links to 15 SMST test positions. The CM is 
equipped to accommodate 30 SMs that are specified in the SMST 
Office-Dependent Data (ODD). Figure 2 shows the SMST configuration. 
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Fig. 3—Switching module system test position. 


Two types of communication occur between each SMST test position 
and the SMST Host System. First, an SM being tested with the 
SMST Host System communicates with the CM through NCT links. 
Second, each system tester communicates with the AM via an I/O 
terminal. One I/O is assigned per test position. This terminal is used 
for input messages such as diagnostic requests and status requests. 
Output messages associated with a particular SM are routed from the 
AM to the terminal at the appropriate SMST test position. A printer - 
is provided at each SMST test position for use whenever a hard copy 
printout is desired. Figure 3 shows an SMST test position. 


5.2 ODD for SMST 


The ODD for each SMST Host System defines the database for 30 
SMs. This ODD is specifically generated for SMST on a support 
computer in the factory. The SMST ODD Administrator generates 
the SMST ODD by specifying on this support computer the next 30 
SMs scheduled to be tested with a particular SMST Host System. 
The SMST ODD generation process combines information from the 
ODDs for SMs from various 5ESS switches. Since diagnostics rather 
than call processing are used during SMST, no call-processing infor- 
mation is included in the SMST ODD. Instead, only information 
defining the equipment configuration is included. The SMST ODD 
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consists of 30 files for each of the SMs to be tested plus one file 
containing the ODD for the AM. 

A new SMST ODD is installed as soon as testing has begun on the 
last of the 30 SMs specified in the old SMST ODD. After completion 
of this process, new SMs can be tested using the SMST Host System. 
The test requirements each SM must meet before the completion of 
SMST are summarized in the next section. 


5.3 SMST test requirements 


The requirements for an SM to complete SMST are stated in a 
specification developed by AT&T Bell Laboratories. Adherence to 
these test requirements in the factory is verified on sampled SMs by 
the AT&T Network Systems quality-assurance organization. These 
requirements are summarized as follows: 

1. All circuit packs, including spares, must meet stress-test require- 
ments before SMST. 

2. All SMPUs and TSIUs must have previously passed unit testing. 

3. All plug-in units to be shipped with the SM must be tested in 
SMST. 

4, All SMs tested in SMST but not tested in MMST must be able 
to process call traffic at the completion rate and with quality equal to 
MMST requirements. 

5. All diagnostics, including all demand phases, must pass. The LU 
grid fabric exercise must also pass. 

6. The SMST Host System must be able to pump the memory of 
each SM. 

7. Each SM must pass a heat test. 

The next section specifies the SMST testing strategy and contains 
more details on the SM pump test and SM heat test performed in 
SMST. 


5.4 SMST testing strategy 


SMST testing is performed as specified by a detailed FST procedure. 
The three stages of the SMST procedure are reviewed in the following 
sections. 


5.4.1 Preliminary procedures 


The preliminary SMST procedures must be completed before an 
SM can be tested with the SMST Host System. These procedures are 
as follows: 

1. Equipment in the SM frames is visually checked to ensure that 
the SM is properly equipped. 

2. The message time-slot switches on the SM are set to specify the 
SM number specified in the SMST ODD. 
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3. The I/O terminal associated with the test position is initialized 
so that SM-related output messages from the SMST Host System are 
directed to the terminal at the proper SMST test position. 

4. The system tester next verifies that both power and fusing for 
the SM have been correctly installed. 

5. Circuit packs are inserted. The only circuit packs that will have 
been installed previously in the frames and unit tested are the SMPU 
and TSIU packs. All other circuit packs in the SM come directly to 
SMST from the circuit-pack test and are inserted into the frames at 
the SMST test position. 

6. All SM cables are verified. The final step in the preliminary 
SMST procedures is the connection of the NCT links. A flexible SM 
numbering capability in the generic program allows NCT links to be 
reassigned to the particular SM being connected. Recent change 
messages provide this reconfiguration capability. Functional testing of 
the SM with the SMST Host System is now ready to begin. 


5.4.2 SM functional test 


The process of functionally testing an SM begins by placing the SM 
into SM min-mode. The SM’s memory (both generic program and 
ODD) is pumped from files on the AM’s disk, and the SM is initialized. 
After the SM has been initialized successfully, units in the SM are 
diagnosed in the sequence specified below. Preprinted forms for re- 
cording diagnostic test results are provided to SMST personnel. 

1. SMPUs. The SMPU diagnostic includes the switching module 
processor, TSIU, control interface, Data Interface (DI), and signal 
processor. 

2. Fast-Pump Bootstrapper. This is the circuit pack used to fast 
pump the SM’s memory. 

3. Dual-Link Interface (DLIs). The DLIs are the SM interfaces for 
the NCT links connecting to the TMS. 

4. Peripheral Units. The specific peripheral units in each SM are 
engineered by the operating companies to meet their individual re- 
quirements. With Generic 5E2(1) the possible SM peripheral units are 
local digital service units, global digital service units, LUs, TUs, 
modular metallic service units, DLTUs, digital carrier line units, 
directly connected test units, and facility interface units for RSMs. In 
addition to diagnosing all peripheral units, the LU grids are exercised 
using the grid fabric exerciser program. Peripheral units are functionally 
tested in SMST using many of the features previously described in 
Section IV. Diagnostics are run using the concurrent diagnostic and 
global diagnostic features. The current status of SM diagnostic requests 
can be determined from the diagnostic status report. A cumulative 
record of all SM diagnostic results can be determined from the 
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diagnostic test status report. After all peripheral units have been 
successfully diagnosed, the SM is removed from SM min-mode. 

The capability to successfully pump the SM’s memory from the 
SMST Host System using different link combinations is tested. Both 
control time slot and fast pump are used during this test. 


5.4.3 Heat test 


The SMST heat test is designed to eliminate marginal circuit packs 
and at the same time provide complete diagnostic verification of the 
SM. During temperature elevation the temperature is raised from 
ambient room temperature to 49°C. As the temperature level is raised, 
the active SMPU is switched every five minutes. This exercises the 
SM instead of running system diagnostics during temperature elevation. 

After the temperature has been stabilized at between 47 and 49°C, 
all SM diagnostics and the grid fabric exerciser are run. The standby 
SMPU is then made active and the diagnostics and grid fabric exerciser 
are repeated. During the second set of diagnostics no major alarms or 
initializations can occur because of the SM being tested. No more 
than one hardware-related interrupt in a two-hour interval is allowed. 
If these requirements have not been met after completion of the second 
set of diagnostics, the stabilized temperature interval is continued with 
diagnostics running until a full two-hour interval occurs that satisfies 
these requirements. 

If at any time a failure is encountered, the failure is resolved and 
the system is soaked for a 15-minute interval before proceeding. 
Furthermore, if a failure occurs during either temperature elevation or 
depression, the temperature is held constant during the 15-minute 
soak interval following resolution of the problem. 

After the SM has passed the heat test requirements, the temperature 
is allowed to return to the normal ambient level. The active SMPU is 
switched every 5 minutes while this occurs. When the temperature 
has returned to normal, all diagnostics and the grid fabric exerciser 
are run one more time. Any problems encountered are resolved. After 
this final verification at room temperature, SMST is complete. 

The first two SMs for each office are tested in SMST before other 
SMs for the office so that these SMs will be available for MMST. The 
following section describes the MMST process. 


Vi. MULTIMODULE SYSTEM TEST 


The purpose of MMST is to simulate field operation of the 5ESS 
switch in the factory on a limited scale using the first two SMs from 
an office. This ensures that there is a known working base configuration 
when a 5ESS switch is first installed in the field. 
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Fig. 4—Multimodule system test configuration. 





6.1 MMST configuration 


The 5ESS switching equipment tested at each MMST test position 
consists of the AM, CM, and SM, and SMb. All the major units in 
MMST successfully complete either a unit or system test before 
MMST begins. The AM is fully system tested in the test of the 3B20D 
computer; in the CM, both the MSGS and TMS are unit tested; and 
both SM, and SM, are system tested in SMST. 

Each of the pre-MMST unit-test and system-test activities listed 
above includes a heat test. Therefore no additional heat test is required 
during MMST.. All circuit packs that fail during MMST are replaced 
with packs that were previously heat tested. 

Special test equipment is required for MMST and is permanently 
installed at each MMST test position. This equipment includes an 
MCC terminal and ROP that allow factory system test personnel to 
communicate with the system being tested. A programmable call 
generator is used to generate calls during MMST call-volume testing. 
A distributing frame is provided for interconnecting the test lines 
required for call-volume testing. Figure 4 shows the MMST configu- 
ration. 
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6.2 ODD for MMST 


The ODD used during MMST is the same special ODD initially 
used when a 5ESS switch is installed in the field. This special ODD, 
known as Factory and Installation Test Translations (FITTs), contains 
all equipment-related data required for cutover of the office. The final 
ODD installed shortly before turnover contains the customer line data. 
FITTs provides a set of test line data with which both MMST and 
the installing office perform call-volume testing and operationally test 
the LUs. Call-volume testing is performed with all LUs in the first 
two SMs during MMST and with all LUs in the office during 
installation. 

The FITTs database is generated on a support computer in the 
factory. After MMST the FITTs database is shipped to the field with 
the system. 


6.3 MMST test requirements 


The requirements for a system to complete MMST are stated in a 
specification developed by AT&T Bell Laboratories. Adherence to 
these test requirements in the factory is verified on sampled MMST 
configurations by the AT&T Network Systems quality-assurance or- 
ganization. These requirements are summarized as follows: 

1. The AM, CM, and SMs tested in MMST must have successfully 
passed system testing of the 3B20D computer, CM unit tests, and 
SMST, respectively. 

2. All system cables and cabinets used during MMST must be the 
same ones shipped with the system. Cabinets tested in MMST must 
contain the specific plug-in units (including power converters) shipped 
to the field. 

3. All circuit packs, including spares, must meet stress-test require- 
ments before MMST. 

4. All diagnostics, including all demand phases, must pass. 

5. A call-volume test with the two SMs must be successfully 
completed. 

6. A half-office test must be successfully completed. 

7. A full-office link test must be performed for all equipped SM 
positions. 

8. A system-initialization test must be successfully completed. 

The next section specifies the MMST testing strategy and contains 
more details on the call-volume test, half-office test, full-office link 
test, and system-initialization test. 


6.4 MMST testing strategy 


MMST testing is performed as specified by a detailed FST procedure. 
The eight stages of the MMST procedure are described in the following 
sections. 
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6.4.1 Preliminary procedures 


The preliminary MMST procedures must be completed before 
MMST testing can begin. The AM, CM, and first two SMs are 
installed in the MMST test position, and system cables are connected. 
The MCC terminal and ROP permanently located at the MMST test 
position are connected to the system. After a complete inspection of 
the power circuitry to ensure there are no broken fuses, wires, or 
connectors, a detailed power-up procedure is followed. 


6.4.2 AM test 


Although the AM has previously completed system testing of the 
3B20D computer, additional testing of the AM emphasizing initializa- 
tion and reconfiguration capabilities is completed in MMST. All AM 
diagnostics are run with each processor active. After all the AM 
diagnostics pass, testing can begin on the CM. 


6.4.3 CM test 


Testing of the CM begins by placing the system in AM min-mode. 
CM units are diagnosed in the following order: (1) MSGSs, (2) 
foundation peripheral controller, (3) pump peripheral controller, (4) 
module message processor, and (5) office network timing control. The 
office network timing control consists of the message interface and 
clock unit, TMS, and the DLIs in the two SMs. After all the CM 
diagnostics pass, testing can begin on the two SMs. 


6.4.4 SM test 


All diagnostics are run on each SM and any diagnostic failures are 
resolved. Since the two SMs tested in MMST have already completed 
SMST, few if any problems are encountered. After both SMs have 
been successfully diagnosed, the system is ready for the MMST call- 
volume test. 


6.4.5 Call-volume test 


The call-volume test is performed in MMST using line-to-line traffic 
generated by a programmable call generator. Sixteen test lines defined 
in the FITTs database are connected from each LU to the distributing 
frame permanently located in the MMST test position. These lines 
are cross-connected from the distributing frame to the programmable 
call generator. Both dial-pulse and Touch-Tone signaling calls are 
generated by the programmable call generator. The hourly call rate 
used is 750 times the number of line units in the first two SMs. The 
length of the call-volume test is 12 hours. The following are requirements 
that must be met before the call-volume test is completed: 

1. The call completion rate must be 99.99 percent or greater. 

2. There can be no more than one interrupt per 10,000 calls. 
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3. There can be no more than one audit or single-process purge per 
2000 calls. 

4, Per-call test failures must be less than 0.1 percent. 

5. No more than 0.5 percent of all calls can experience dial-tone 
delay greater than three seconds. 

6. No system inhibits may be set during the test. 


6.4.6 Half-office test 


During a half-office test the system runs first with one half of the 
office powered down and then with the other half powered down. All 
duplicated units in the AM, CM, and SMs are included in this test. 
The system operates on each half for one hour with a call load. The 
call-completion rate and system problem counts must meet the criteria 
specified in Section 6.4.5 for the MMST call-volume test. 


6.4.7 Full-office link test 


Although MMST only involves two SMs, a comprehensive test of 
the CM, known as the full-office link test, is performed in MMST to 
operationally test the CM links associated with all SMs in the office. 
The NCT links from SM, are sequentially connected to each SM 
position in the TMS from 3 through the maximum SM number. 
Although the hardware configuration of SM, will not necessarily match 
the ODD for any of the other SMs, the memory of SM, can still be 
successfully pumped while connected to each SM position in the TMS. 
This link test procedure is repeated as SM, is rotated through every 
equipped SM position in the TMS. 


6.4.8 System-initialization test 


In MMST the system is tested to ensure that the AM, CM, and 
SMs can be fully initialized with the generic from either side of the 
AM using either primary or secondary disk file controllers. No inhibits 
may be set when this test is performed. 

The standard configuration of the 5ESS switch includes a spare 
disk drive in addition to the active and standby disk drives. This spare 
disk drive can be used as a backup for either of the other two disk 
drives. The final stage of MMST involves testing the spare disk drive 
and the spare disk. After this test, MMST is complete. 


Vil. QUALITY-ASSURANCE PLAN 
7.1 Quality-assurance requirements 

Each 5ESS. switch must meet demanding quality requirements 
throughout the manufacturing process. The Quality-Assurance (QA) 
organization applies final factory quality audits following SMST and 
MMST. Both visual and functional checks are required. A rigorous 
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sampling of 5ESS switching equipment determines the overall accept- 
ability of the product. 

There are two types of operational checks for 5ESS switches. First, 
functional audits measure the hardware performance against normal 
operating criteria. These audits include application of all system 
diagnostics (SMST and MMST), call-volume testing (MMST), half- 
office testing (MMST), and system-initialization testing (SMST and 
MMST). Second, reliability audits measure system performance under 
stress. Elevated temperatures are applied for 48 hours while the system 
is heavily exercised using volume traffice (MMST) and system diag- 
nostics (SMST and MMST). The QA organization conducts the audit 
and it reports statistically derived results based on the equipment 
sampled. 


7.2 Quality-assurance procedures 


The QA organization decides randomly which SMs from SMST and 
which MMST configurations will be audited. The QA organization can 
perform either a functional audit or a functional audit and a reliability 
audit. All hardware failures are reported by the QA organization. 
Additional quality-assurance checks ensure that all equipment to be 
supplied by the factory is equipped. The factory is responsible for 
correcting all problems before shipping the system. 


Vill. SUMMARY 


FST of the 5ESS switch, the final stage in the factory test process, 
ensures that each 5ESS switch shipped to the field meets specific 
system-level requirements. Consideration of the distributed architecture 
of the 5ESS switch in the design of this test process contributes 
significantly to the cost-effectiveness of FST for the 5ESS switch. All 
SMs are tested in SMST, and the first two SMs from each office are 
tested in MMST with the office’s AM and CM. The parallelism that 
is possible with SMST and MMST results in significant cost savings. 

The FST environment provides a more stressful set of conditions 
for the diagnostics and maintenance software than is normally en- 
countered in an in-service office. However, diagnostic and maintenance 
features of the 5ESS switch allow the standard generic program to be 
used for FST. These features include min-mode, the diagnostic envi- 
ronment, hardware troubleshooting features, and a message routing 
feature used in SMST. 

System-level test requirements that must be met in both SMST and 
MMST are specified. A quality-assurance program in the factory 
verifies on a sampling basis that 5ESS switches either meet or exceed 
these requirements. Thus, the successful completion of FST for the 
5ESS switch is a major factor in assuring that each 5ESS switch 
delivered to the customer will provide high-quality service after cutover. 
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ACRONYMS AND ABBREVIATIONS 


2SCCS 
5EDOPS 
ABS 
ALIT 

AM 
AMARC 
AMATPS 


AMATS 
ANI 

AP 

APT 

ASW 
BORSCHT 


CA 
CAD 
CAMA 
CAROT 
CCIS 
CCITT 


C/D 
CDF 
CDO 
CEMF 
CFM 
Cl 
CKT 
CLK CNT 
CLM 
CM 
CMGA 
CMS | 
COT 
CP 
CRA 
CTTU 
DART 
DBM 
DBMS 
DCLU 


2 Switching Control System Center 

5ESS™ Switch Digital Ordering and Planning System 
average busy season 

automatic line insulation testing 

administrative module 

automatic message accounting recording center 
Automatic Message Accounting Teleprocessing/Tape 
System 

Automatic Message Accounting Teleprocessing System 
automatic number identification 

administrative processor 

automatic progression testing 

all seems well 

battery feed, overvoltage protection, ringing, supervi- 
sion, coding and decoding, hybrid, and testing 
coverage analyzer 

computer-aided design 

centralized automatic message accounting 
Centralized Automatic Reporting on Trunks 

common channel interoffice signaling 

International Telegraph and Telephone Consultative 
Committee 

control and display 

combined distributing frame 

community dial office 

counter-electromotive force 

cubic feet per minute 

control interface 

circuit 

clock control 

communication-link monitor 

communications module 

craft message generator analyzer 

Change Management System 

central office terminal 

central processor 

call record assembler 

central trunk test unit 

debugger for remote target 

data base management, manager 

data base management system 

digital carrier line unit 
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KAI 
EAS 
ECSA 
EDLCP 
EE 
EMF 
ESD 
ESR 
FC 
FIDB 
FITT 
FIU 
FOA 
FPC 
FST 
GDSU 
GDX 
HIC 
HLSC 
HOC 
HSM 
IC 
IMPU 
IMR 
IOP 
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directly connected test unit 
distributing frame 

disk file controller 

digital facility interface 

data interface 

dual in-line package 

digital line 

digital loop carrier 

dual-link interface 

digital line trunk unit 

disk power cabinet 

digital service circuit 

digital subscriber line 
double-sided rigid 

digital service unit 

digital cross-connect 

equalizer 

Engineering and Administrative Data Acquisition 
System 

emergency action interface 
extended area service 

Exchange Carrier Standards Association 
external data link communications package 
execution environment 
electromotive force 

electrostatic discharge 

error source register 

feature control 

facilities interface data bus 
factory and installation test translation 
facilities interface unit 
first-office application 
foundation peripheral controller 
factory system testing 

global digital service unit 

gated diode crosspoint 

hybrid integrated circuit 
high-level service circuit 

host collector 

host switching module 
interexchange carrier 

improved module processor unit 
initial modification request 
input/output processor 
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ISDN 
ITS 
IU 
LAMA 
LATA 
LCR 
LDSU 
LI 
LNI 
LOTS 
LP 
LPCDF 
LSI 
LSP 
LTD 
LTP 
LTS 
LTS 
LU 
MCC 
MCS 
MCTSI/DLI 


MDF 
MECCA 
MHD 
MI 
MICU 
MLB 
MLI 
MLT 
MLTS 
MML 


integrated services digital network 
Integrated Test System 

interface unit 

local automatic message accounting 
local access and transport area 

line concentration ratio 

local digital service unit 

link interface 

line interface 

Load Originating Test System 

large processor 

low-profile conventional distributing frame 
large-scale integration 

laboratory support processor 

local test desk 

line trunk peripheral 

laboratory test system 

loop testing system 

line unit 

master control center 

microcontrol store 

module controller time-slot interchanger/dual-link in- 
terface 

main distributing frame 
Mechanized Evaluation of Call Completion Anomalies 
moving head disk 

message interface 

message interface clock unit 
multilayer board 

message link interface 

mechanized loop testing 

multiline telephone set 
man-machine language 

module message processor 
multimodule system test 

modular metallic service unit 
modular metallic service unit growth 
module processor 

modification request 

message switch 

message switch control unit 
message switch 

message switch 

message switch peripheral processor 
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MSPU 
MSU 
MUX 
NAC 
NCLK 
NCT 
NEBS 
NMC 
OAM 
OA&M 
ODD 
ORB 
OSDS 
OSPS 
OSS 
OTC 
P 
PABX 
PAG 
PC 
PCC 
PCCA 
PCFD 
PCM 
PDC 
PDL 
PECC 
PICB 
PIDB 
PLL 
PMO 
POTS 
PPC 
PPM 
PS 
PSS 
QA 
R-DFI 
RAU 
RC 
RC/V 
RC/V LOCAL 
REX 
RMAS 


message switch peripheral unit 
metallic service unit 

multiplexer 

network administration center 
network clock 

network control and timing 

New Equipment-Building System 
network management center 

once a month 

operations, administration, and maintenance 
office-dependent data 

office repeater bay 

operating system for distributed switching 
Operator Service Position System 
operations support system 
operating telephone company 
pairs 

private automatic branch exchange 
program administration group 
peripheral control 

program change committee 
processor controller cabinet 
power distribution cabinet 

pulse code modulation 

power distribution cabinet 
peripheral diagnostic language 
product evaluation control center 
peripheral interface control bus 
peripheral interface data bus 
phase-locked loop 

present method of operation 
plain old telephone service 

pump peripheral controller 
periodic pulse metering 

power start 

Programmer Support System 
quality assurance 

RSM digital facility interface 
recorded announcement unit 
recent change 

recent change and verify 

recent change and verify local 
routine exercise | 

Remote Memory Administration System 
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ROP 
ROP 
ROTL 
RPI 
RSB 
RSM 
RSS 


RTA 
RTAC 
RTTU 
SCANS 


SCC 
SCCS 
SDE 
SDLC 


SES-2 
SGS 
SIU 


SMC 
SMP 
SMPU 
SMST 


SPC 
SPP 
STLWS 
T&R 
TAU 
TCBH 
TLM 
TLP 
TLWS 
TMCU 
TMS 
TMSU 
TNDS 
TRUMP 


TSIU 
TSPS 


read-only printer 

receive-only printer 

remote office test line 

return to point of interrupt 
repair service bureau 

remote switching module 

remote switching system 

remote terminal 

routing and terminal administration 
regional technical assistance center 
remote trunk test unit 

Software Change Administration and Notification 
System 

switching control center 
Switching Control Center System 
system development environment 
synchronous data link control 
Service Evaluation System 
Service Evaluation System-2 
Software Generation System 
SLC® carrier interface unit 
switching module 

switching module control 
switching module processor 
switching module processor unit 
switching module system test 
signal processing, processor 
stored program control 

single process purge 
supplementary trunk line work station 
tip and ring 

test access unit 

time-consistent busy hour 
trouble-locating manual 
trouble-location procedure 

trunk line work station 
time-multiplexed control unit 
time-multiplexed switch 
time-multiplexed-switch unit 
Total Network Data System 
trunk maintenance package 
time-slot interchanger 

time-slot interchange unit 

Traffic Service Position System 
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TTF transmission test facility, function 


TTY teletypewriter 

TU trunk unit 

TUCA tape unit cabinet 

UCC universal conference circuit 
UTD universal tone decoder 
UTG universal tone generator 
VDT video display terminal 
VDU video display unit 

VLSI very-large-scale integration 
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